Gerçekten de MVC nedir?

Ciddi bir programcı olarak, MVC nedir sorusuna nasıl cevap veriyorsunuz ?

Aklımda, MVC çok kötü bir konudur - ve bu nedenle, eğer izleyicileriniz bir öğreniciyse, tartışmalı olması muhtemel olmayan genel terimlerle tarif etmekte özgürsünüz.

Ancak, bilgili bir kitleyle, özellikle de bir görüşmeci ile konuşuyorsanız, "doğru bir şey değil! ..." tepkisini riske atmayacak bir yön belirleme konusunda çok zorlanıyorum. Hepimizin farklı gerçek dünya deneyimleri var ve aynı MVC uygulama modelini iki kez gerçekten karşılamadım.

Spesifik olarak, sertlik, bileşen tanımı, parçaların ayrılması (hangi parçanın nereye uyduğu), vb. İle ilgili anlaşmazlıklar var gibi görünmektedir.

Öyleyse, MVC'yi doğru, özlü ve tartışmasız bir şekilde nasıl açıklamalıyım ?

MVC, etki alanı / uygulama / işletme (neyi tercih ederseniz) mantığını kullanıcı arayüzünün geri kalanından ayıran bir yazılım mimarisidir - sistemin yapısıdır. Bunu, uygulamayı üç bölüme ayırarak yapar: model, görünüm ve kontrolör.

Model, uygulamanın temel davranışlarını ve verilerini yönetir. Bilgi taleplerine cevap verebilir, bilgisinin durumunu değiştirme talimatlarını yanıtlayabilir ve hatta bilgi değiştiğinde olaya dayalı sistemlerdeki gözlemcileri bilgilendirebilir. Bu bir veritabanı veya herhangi bir sayıda veri yapısı veya depolama sistemi olabilir. Kısacası, uygulamanın veri ve veri yönetimidir.

Görünüm, uygulamanın kullanıcı arayüzü öğesini etkili bir şekilde sağlar. Modelden verileri kullanıcı arayüzüne uygun bir formata sokacaktır.

Kontrolör kullanıcı girişi alır ve model nesneleri çağırır ve uygun işlemleri yapmak için görünümü gösterir.

Sonuç olarak, bu üç bileşen, MVC'nin üç temel bileşenini oluşturmak için birlikte çalışır.

analoji

MVC’yi babama şu şekilde açıkladım:

MVC (Model, Görünüm, Kontrolör), bir uygulamada bakımı kolaylaştırmak için kod düzenlemek için kullanılan bir kalıptır.

Bir stüdyoda kamerasıyla bir fotoğrafçı düşünün. Bir müşteri ondan bir kutunun fotoğrafını çekmesini ister.

Kutu model , fotoğrafçı denetleyici ve kamera görüntüdür .

Kutu kamera veya fotoğrafçı hakkında bir şey bilmediğinden tamamen bağımsızdır. Bu ayrılık, fotoğrafçının kutunun etrafında dolaşmasını ve istediği çekimi / manzarayı elde etmek için kamerayı herhangi bir açıyla işaret etmesini sağlar.

MVC olmayan mimariler birbirine sıkı sıkıya entegre olma eğilimindedir. Kutu, denetleyici ve kamera aynı nesneden biriyse, yeni bir görünüm elde etmek istediğimizde hem kutuyu hem de kamerayı söküp yeniden inşa etmemiz gerekirdi . Ayrıca, fotoğraf çekmek her zaman bir selfie çekmeye çalışmak gibi olurdu - ve bu her zaman çok kolay değil.

Detaylı açıklama

MVC'yi anladığımı hissettim, ancak aşağıdaki postacı soruyu / cevabı okuduktan sonra oldu. Alıntı: https://mail.python.org/pipermail/python-list/2006- Ocak / 394968.html

bwaha yazdı:

Yazar, MVC tasarımının bir örneği olarak wxPython'daki mvctree.py dosyasına atıfta bulunur. Ancak hala çok yeşil olduğumdan, bu özel örneği çok karmaşık buluyorum ve yazarın önerdiği ayrımları anlamıyorum.

MVC, endişelerin ayrılması ile ilgilidir.

Modelin program verilerini yönetmekten sorumludur (hem özel hem de müşteri verileri). Görünüm / Kontrolör, dış dünyaya programın müşteri verileriyle etkileşimde bulunmak için araçlar sağlamaktan sorumludur.

Model, programın diğer bölümlerinin onunla etkileşime girmesini sağlamak için bir iç arayüz (API) sağlar. Görünüm / Denetleyici, programın dışındaki her şeyle iletişim kurmasını sağlamak için harici bir arabirim (GUI / CLI / web formu / üst düzey IPC / vb.) Sağlar.

Modelin program verilerinin bütünlüğünü korumaktan sorumludur, çünkü eğer bu bozulursa herkes için oyun biter. Görünüm / Denetleyici, kullanıcı arabiriminin bütünlüğünün korunmasından, tüm metin görünümlerinin güncel değerler gösterdiğinden, geçerli odak için geçerli olmayan menü öğelerinin devre dışı bırakıldığından vb. Sorumludur.

Model Görünüm / Denetleyici kodu içermiyor; GUI widget sınıfı yok, iletişim kutuları düzenlemek veya kullanıcı girişi almak için kod yok. Görünüm / Kontrolör Model kodu içermiyor; URL'lerin doğrulanması veya SQL sorgularının gerçekleştirilmesi için kod yoktur ve orijinal durumların hiçbiri yoktur: widget'lar tarafından tutulan veriler yalnızca görüntüleme amaçlıdır ve yalnızca Modelde depolanan gerçek verilerin bir yansımasıdır.

Şimdi, işte gerçek bir MVC tasarımının testi: programın bir Görüntü / Denetleyici takılı olmasa bile özünde tamamen işlevsel olması gerekir. Tamam, dış dünya onunla bu şekilde etkileşime girmekte zorlanacak, ancak uygun Model API gelişmelerini bildiği sürece, program verileri normal şekilde tutacak ve değiştirecektir.

Bu neden mümkün? Basit cevap, Model ve Görünüm / Denetleyici katmanları arasındaki düşük bağlantı sayesinde hepsi bu. Ancak, bu tam hikaye değil. Ne bütün MVC deseni anahtarıdır olan yönü TÜM talimatları akış: O bağlantı gider hangi gelen Görünüm / Kontrolör için Modeli. Model ASLA Görünüm / Denetleyiciye ne yapacağını söylemez.

Neden? Çünkü MVC’de, Görünüm / Denetleyici Model hakkında biraz bilgi sahibi olurken (özellikle Model API’sı), ancak Model Görünüm / Denetleyici ile ilgili herhangi bir şey bilmesine izin verilmez.

Neden? Çünkü MVC endişelerin net bir şekilde ayrılmasıyla ilgilidir.

Neden? Programın karmaşıklığının kontrolden çıkmaması ve sizi, geliştiricinin altından gömülmesini önlemeye yardımcı olmak için. Program büyüdükçe, programdaki bileşen sayısı da artar. Ve bu bileşenler arasında daha fazla bağlantı var, geliştiricilerin ayrı ayrı bileşenleri korumasını / genişletmesini / değiştirmesini, hatta tüm sistemin nasıl çalıştığını takip etmesini zorlaştırıyor. Kendinize şunu sorun: programın yapısının bir şemasına bakarken, bir ağaç mı yoksa bir kedinin beşiği mi görmek istersiniz? MVC paterni, dairesel bağlantıları devre dışı bırakarak ikincisini önler: B, A'ya bağlanabilir, ancak A, B'ye bağlanamaz. Bu durumda, A, Model'dir ve B, Görüntü / Denetleyici'dir.

BTW, keskinseniz, daha önce açıklanan 'tek yönlü' kısıtlamada bir sorun olduğunu fark edeceksiniz: Model, Model bile izin verilmediğinde Model'in kullanıcı verilerindeki değişikliklerin Görünümü / Denetleyicisini nasıl bilgilendirebilir? View / Controller'ın mesaj göndermeye aldırış etmediğini biliyor musun? Ancak endişelenmeyin: Bunun bir çözümü var ve ilk başta biraz dolambaçlı görünse de oldukça temiz. Birazdan buna geri döneceğiz.

Daha sonra, pratik olarak, bir View / Controller nesnesi, Model'in API'sı aracılığıyla, 1. Model'e bir şeyler yapmasını söyler (komutları yürütür) ve 2. Model'e bir şeyler vermesini söyler (veri döndürür). Görünüm / Denetleyici katmanı, talimatları Model katmanına iter ve bilgileri Model katmanından çeker .

İlk MyCoolListControl örneğinizin yanlış gittiği yer burasıdır, çünkü o sınıfın API'si bu bilginin içine itilmesini gerektirir , bu nedenle katmanlar arasında iki yönlü bir bağlantı kurmaya, MVC kurallarını ihlal etmeye ve sizi doğrudan geri almaya başlıyorsunuz Kedinin beşiği mimarisi [muhtemelen] ilk etapta kaçınmaya çalışıyordu.

Bunun yerine, MyCoolListControl sınıfı, ihtiyaç duyduğu zaman aşağıdaki katmandan ihtiyaç duyduğu verileri çekerek akışa devam etmelidir. Bir liste gereci söz konusu olduğunda, bu genellikle kaç değer olduğunu sormak ve daha sonra sırayla bu maddeleri sormak anlamına gelir, çünkü bu, onu yapmanın en basit ve en gevşek yoluyla ilgilidir ve bu nedenle de kuplajı minimumda tutar. Ve eğer widget bu kullanıcıya kullanıcıya güzel bir alfabetik sıraya göre dizmek isterse, o zaman bu perogatif; ve elbette ki sorumluluğu.

Şimdi, daha önce de bahsettiğim gibi son bir bilmece: UI ekranını Modelin durumu ile MVC tabanlı bir sistemde nasıl senkronize ediyorsun?

İşte problem: birçok View nesnesi durumludur, örneğin bir onay kutusu işaretlenebilir veya işaretlenmemiş olabilir, bir metin alanı düzenlenebilir bir metin içerebilir. Bununla birlikte, MVC tüm kullanıcı verilerinin Model katmanında saklanmasını zorunlu kılar, bu nedenle görüntüleme amacıyla diğer katmanlar tarafından tutulan herhangi bir verinin (onay kutusunun durumu, metin alanının geçerli metni) bu nedenle bu birincil Model verilerinin bir kopyası olması gerekir. Ancak Modelin durumu değişirse, Görünüm'ün bu durumun kopyası artık doğru olmayacak ve yenilenmesi gerekecektir.

Ama nasıl? MVC deseni, Modelin bu bilgilerin yeni bir kopyasını Görünüm katmanına sokmasını önler. Heck, Modelin Durumun değiştiğini söylemek için bir Mesaj göndermesine bile izin vermiyor.

Neredeyse. Tamam, Model katmanının doğrudan diğer katmanlarla konuşmasına izin verilmez, çünkü bunu yapmak için bu katmanlarla ilgili bir şeyler bilmesi gerekir ve MVC kuralları bunu önler. Bununla birlikte, bir ağaç ormana düşerse ve kimse duymayacaksa, ses çıkarır mı?

Yanıt, gördüğünüz gibi, Model katmanına kimseye ilan edemeyeceği bir yer sağlayarak, özellikle ilginç bir şey yaptığını bildiren bir bildirim sistemi kurmaktır. Diğer katmanlar daha sonra, gerçekten ilgilendikleri duyuruları dinlemek için bu bildirim sistemiyle dinleyicileri gönderebilir. Model katmanı kimin dinlediği hakkında bir şey bilmek zorunda değildir (veya birileri dinliyor olsa bile!); sadece bir duyuru yayınlar ve sonra unutur. Ve eğer biri bu duyuruyu duyarsa ve daha sonra bir şeyler yapmak istiyorsa - Modelden bazı yeni veriler istemesini isteyin, böylece ekran görüntüsünü güncelleyebilir - o zaman harika. Model sadece API tanımının bir parçası olarak hangi bildirimleri gönderdiğini listeler; ve bu bilgiyle başkasının yaptığı şey onlara bağlıdır.

MVC korunur ve herkes mutludur. Uygulama çerçeveniz yerleşik bir bildirim sistemi sağlayabilir ya da yoksa kendiniz yazabilirsiniz ('gözlemci modeline bakın).

...

Neyse, yardımcı olur umarım. MVC'nin arkasındaki motivasyonları anladıktan sonra, işlerin neden yapıldığı gibi yapılmasının sebepleri, ilk bakışta bile gerekenden daha karmaşık göründüğünde bile, anlamlı olmaya başlar.

Alkış,

vardır

MVC çoğunlukla bir terimdir.

Eskiden bir model olarak kabul edilirdi, ancak 1979 orjinal tanımı aptallaştırıldı, aktarıldı, yanlış yorumlandı, orijinal bağlam dışına çıkarıldı. Bir dine benzemeye başladığı noktaya göre yeniden tanımlandı ve bu kesinlikle yük kültürcülerinin onu savunmasına yardım etmesine rağmen, adı artık katı bir kurallar dizisiyle ilişkilendirmiyor . Bu nedenle, artık gerçekten bir model olarak kabul edilemez.

MVC hiçbir zaman web uygulamalarını tanımlamak için kullanılmamıştı.
Modern işletim sistemleri ve dilleri de.
(bazıları 1979 tanımını gereksiz kılan)

Yapıldı. Ve işe yaramadı.

Şimdi , korkunç terim bilgisi durumu, kötü tanımı ve yarı okuma yazma bilmeyen programcılarını hedef demografik olarak tanımlayan, genel olarak yazılım kalıplarına çok kötü bir tanıtım yapan, müstehcen bir web-mvc melezi ile uğraşıyoruz .

Bu nedenle MVC, fazla düşünmek istemeyen insanlar için damıtılmış endişelerin ayrılması oldu .

• Veri modeli, tek bir şekilde ele alınır
• görünüşüdür başka,
• Gerisi sadece "denetleyici" olarak adlandırılır ve okuyucunun takdirine bırakılır.

90'lı yıllarda web siteleri / web uygulamaları gerçekten kaygıların ayrılmasını uygulamak için kullanılmadı.

Onlar karışık spagetti kodunun korkunç dallarıydı.
UI değişiklikleri, yeniden tasarımları ve veri düzenlemeleri inanılmaz derecede zor, pahalı, uzun, moral bozucu, kötü niyetli idi.

ASP, JSP ve PHP gibi web teknolojileri, verilerle ve uygulamalarla ilgili endişeleri birbirine karışmasını çok kolaylaştırır . Bu alana yeni başlayanlar genellikle eski zamanlardaki gibi ayrılmaz bir kod çamurlukları yayarlar.

Böylece, giderek artan sayıda insan , destek forumlarındaki sonsuz döngülerde "MVC kullan" ı tekrarlamaya başladı . İnsanların sayısı, yöneticileri ve pazarlamacıları da içerecek şekilde genişledi (bazı terimlere zaten, GUI programlamada, örgünün anlam ifade ettiği zamanlardan beri tanıdık gelmişti) ve bu, şimdi yüzleşmek zorunda olduğumuz bir sözcük kelimesi adıydı. .

Olduğu gibi bir metodoloji değil, sağduyu . Bu bir başlangıç ​​noktasıdır , çözüm değil . İnsanlara hava solumasını ya da egzersiz yapmasını söylemek gibi , kanser tedavisi için değil .

Bunu tanımlamanın en iyi yolu , onu icat eden Trygve Reenskaug'un orijinal yazılarına gitmektir : http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html

Bu yazı, özellikle, genel olarak tanımlayıcı metin olarak kabul edilir: http://heim.ifi.uio.no/~trygver/1979/mvc-2/1979-12-MVC.pdf

MODELLER

Modeller bilgiyi temsil eder. Bir model tek bir nesne olabilir (ilgi çekici değil) veya nesnelerin bir yapısı olabilir ...

Bir yandan model ile parçaları arasındaki birebir yazışmalar ve diğer yandan modelin sahibi tarafından algılanan temsil edilen dünya olmalıdır. Bu nedenle, bir modelin düğümleri, problemin tanımlanabilir bir parçasını temsil etmelidir.

Bir modelin düğümlerinin hepsi aynı problem seviyesinde olmalıdır, sorun odaklı düğümleri (örn. Takvim randevuları) uygulama ayrıntılarıyla (örneğin paragraflar) karıştırmak için kafa karıştırıcı ve kötü bir şekil olarak kabul edilir.

GÖRÜŞLER

Bir görünüm, modelinin (görsel) bir sunumudur. Normalde modelin belirli niteliklerini vurgulamak ve diğerlerini bastırmak olacaktır. Dolayısıyla sunum filtresi olarak işlev görüyor .

Modeline (veya model kısmına) bir bakış eklenmiştir ve sunum için gerekli olan verileri sorular sorarak alır. Ayrıca uygun mesajlar göndererek modeli güncelleyebilir. Tüm bu sorular ve mesajlar modelin terminolojisinde olmalıdır, bu nedenle görüş, temsil ettiği modelin niteliklerinin anlamını bilmek zorunda kalacaktır. (Örneğin, modelin tanımlayıcısını sorabilir ve bir Metin örneği bekleyebilir, modelin Metin sınıfında olduğunu varsaymayabilir.)

kONTROLÖRLERİ

Denetleyici, kullanıcı ile sistem arasındaki bağlantıdır. Kullanıcının ilgili görünümleri ekranda uygun yerlere sunmasını sağlayarak girdi girişi sağlar. Kullanıcılara menüler veya başka komut ve veri verme araçları sunarak kullanıcı çıktısı için araç sağlar. Kontrolör bu kullanıcı çıktısını alır, uygun mesajlara çevirir ve bu mesajları bir veya daha fazla görüntüye iletir.

Bir denetleyici görüşlere asla destek olmamalıdır, örneğin aralarına oklar çizerek düğümlerin görüşlerini asla birbirine bağlamamalıdır.

Tersine, bir görünüm fare işlemleri ve tuş vuruşları gibi kullanıcı girdisini asla bilmemelidir. Herhangi bir kullanıcı komutları sırasını tam olarak üreten görünümlere mesajlar gönderen bir denetleyicide bir yöntem yazmak her zaman mümkün olmalıdır.

EDİTÖRLERİ

Bir denetleyici tüm görünümlerine bağlanır, denetleyicinin parçaları olarak adlandırılır. Bazı görünümler , kullanıcının görünüm tarafından sunulan bilgileri değiştirmesine izin veren bir düzenleyici olan özel bir denetleyici sunar . Bu tür editörler denetleyici ve görünümü arasındaki yola eklenebilir ve denetleyicinin bir uzantısı olarak işlev görür. Düzenleme işlemi tamamlandıktan sonra, editör yoldan kaldırılır ve atılır.

Bir editörün, bağlı görüntünün metaforları aracılığıyla kullanıcıyla iletişim kurduğunu, bu nedenle editörün görünümle yakından ilişkili olduğunu unutmayın. Bir denetleyici, görüntülemesini sorarak bir düzenleyiciyi ele geçirir - başka uygun kaynak yoktur.

MVC, iş mantığını sunumdan izole etmek için kullanılan bir tasarım desenidir.

Genellikle pek de başarılı bir şekilde uygulanmadığı, ancak bir çerçevenin temeli olduğu gerçeğiyle, diğer pek çok tasarım deseninden farklıdır.

Bir Strateji kalıbı uygulayan bir uygulama bununla ilgili küçük bir ayrıntı olsa da, bir web uygulamasının MVC tasarım desenini kullandığını söylemek onun mimarisini çok iyi tanımlamaktadır .

MVC, bir sistemin veya alt sistemin aşağıdaki bileşenlerini ayıran bir yazılım tasarımıdır:

1. Model - Uygulamanın durumu veya bileşenleri hakkındaki veriler. Değişiklik veya erişim için rutinler içerebilir.
2. Görünüm - Verilerin yorumlanması (model). Bu sadece görsel bir gösterimle sınırlıdır, ancak sesli, türetilmiş bilgiler (örneğin, başka bir model nesnesine aktarılan istatistikler) vb. Olabilir. Ayrıca, tek bir modelin birden çok görüşü olabilir.
3. Kontrol - Modeldeki değişiklikleri çağırarak sisteme harici girişi işler. Kontrol / görünüm yakından ilgili olabilir (bir UI durumunda). Ancak, görünümden tamamen bağımsız olan diğer harici girişler (ağ komutları gibi) işlenebilir.

MVC'nin benzer bir kavram veya aile örüntüsü olduğunu söyleyebilirim.

Bu makalenin okunmaya değer olduğunu düşünüyorum. Martin Fowler'ın GUI Mimarileri

İlk önce, sorunun kim olduğunu ve ne tür bir cevap aradığını belirlemelisiniz. Bu soruya "Ne anlamda?" Gibi başka bir soru ile cevap veriyorsunuz.

Genel olarak MVC'ye, belirli bir MVC uygulamasına (yani asp.net MVC, bahar MVC, smalltalk MVC, vb.), Teknik olarak ne olduğunu, felsefi olarak ne olduğunu sorabilirsiniz (evet, bir yanı sıra felsefe), vb ..

Eğer bu bir testle ilgili bir soruysa ve sorulardan açıklayıcıyı açıklamasını isteyemezseniz, bağlama dayalı olarak tahmin etmeniz gerekecektir.

İyi, basit bir cevap:

MVC, daha sürdürülebilir bir yazılım sağlamak için yapısal ve davranışsal endişeleri ayırmak için kullanılan bir yazılım kullanıcı arayüzü mimarisidir.

Ayrıca şunları da söyleyebilirsiniz:

Görünümü Kontrol Cihazından Modelden Ayırarak bileşenlerin sorumluluklarına dayalı olarak tecrit edilmesini teşvik eder. Teoride ve genellikle pratikte, bu, sistemin farklı parçalarının birbirine karışmasını ve daha karmaşık sistemler oluşturmasını önleyerek sürdürülebilirliği arttırmaya yardımcı olur.

Ancak, sonunda, bekledikleri cevapları verip vermediğinize karar verilecektir. Sorunun tek çözümü ne tür bir cevap beklediklerini bulmak.

İşte bu konuda söyleyeceğim şey. Bunu mobil uygulamalar açısından açıklamaya çalışırdım, çünkü en çok aşina olduğum şey ve mobil uygulamalar yapmaya başlamadan önce tam olarak anladığımı sanmıyorum.
Örneğin Android alalım.
Sunum katmanı, yani kullanıcı arayüzü (en sık kullanılan) tamamen xml olarak belirtilebilir. Basit olması için, bir xml dosyasının uygulamadaki bir ekranı açıkladığını varsayalım. XML dosyası kontrolleri, kontrollerin düzenini, konumlandırmayı, renkleri, ebadı, string etiketleri ... sunumla ilgili her şeyi belirtir. Ancak ne zaman çağrılacağı, ne zaman ekrana yerleştirileceği hakkında hiçbir şey bilmiyor. Tek başına bir düzen mi yoksa daha büyük bir düzenin parçası mı olacak? İşte gördünüz: Mükemmel VIEW .

Şimdi, ekranın belli bir noktada ekrana yerleştirilmesi gerekiyor, peki nasıl yapmalı? Sizin KONTROL Android'de, Aktivite aradı. Adından da anlaşılacağı gibi, aktivite bazı faaliyetler yapar. Tek amacı, adım 1'de tanımlanan görünümü görüntülemek olsa bile, bir miktar işlem gerçekleştirecektir. Böylece, etkinlik bir görünüm kazandırır ve ekranda gösterir. Görünüm etkinlik hakkında hiçbir şey bilmediğinden, benzer şekilde etkinlik gerçek sunum hakkında hiçbir şey bilmez. Biz (programcılar) faaliyetimizdeki bir kod satırını bile değiştirmeden görünüm düzenini birçok kez yeniden düzenleyebilirdik.

Şimdi, güzel parlak, iyi tanımlanmış xml düzeninizi gerçekten bir şey yapmadan sunmanın pek bir faydası yok. Diyelim ki kullanıcı tarafından girilen verileri saklamak istiyoruz. Faaliyetin, bu işlemin verileri kullanıcıdan almaktan başkasına devretmek (işlem, saklamak, silmek) ile başa çıkması gerekir. Kime geçecek? Peki, bir modele . Bir modeli saf olarak düşünmeyi seviyorum. Uygulama bağlamı hakkında hiçbir şey bilmeyen java sınıfı içinde yaşar. (Uygulamada neredeyse hiç olmayacak).

Diyelim ki üç özelliğe sahip bir sınıf kişim var: isim, adres, yaş. XML tanımlı düzenimin kullanıcı girişi için 3 alanı var: ad, adres, yaş. Etkinliğim, kullanıcı girdisinden üç değeri alır, yeni bir Kişi nesnesi oluşturur ve bazı Kişiye özgü mantığı nasıl kullanacağını bilen bir yöntem çağırır. İşte aldın. Model-View-Controller.

Onlara her zaman paternin yeni bir şey olmadığını ve uzun yıllar boyunca bulunduğunu söyleyerek başlarım ... bu noktada bana meraklı bir görünüm veriyorlar ve BAM!

Ve sonra önceki cevaplar gibi çeşitli noktalardan bahsederdim, ama JB King'in dediği gibi bağlamsal olmanın önemini düşünüyorum. ASP.NET MVC vb.