MVC anti OOP değil midir?

OOP'un arkasındaki ana fikir, veri ve davranışları tek bir varlıkta (nesne) birleştirmek. Prosedürel programlamada veri var ve verileri değiştiren ayrı algoritmalar var.

Model-View-Controller modelinde, veri ve mantık / algoritmalar sırasıyla model ve kontrolör olarak ayrı varlıklara yerleştirilir. Eşdeğer bir OOP yaklaşımında model ve kontrolör aynı mantıksal varlığa yerleştirilmemeli midir?

MVC, UI mimarisi olan Endişelerin Ayrılmasında bir alıştırmadır . Sunumun içerikten ayrılmaması nedeniyle kullanıcı arayüzlerinde meydana gelebilecek karmaşıklığı düzeltmenin bir yoludur .

Teoride, tüm nesneler içerdikleri veriler üzerinde çalışan davranışlara sahip olabilir ve bu veriler ve davranış kapsüllenmiş kalır . Uygulamada, belirli bir OOP nesnesi, verisine karşılık gelen bir mantığa sahip olabilir veya olmayabilir veya hiç bir mantığa sahip olmayabilir ( örneğin, bir Veri Aktarım Nesnesi ).

MVC'de iş mantığı denetleyiciye değil modeline gider. Kontrolör, Görünüm ile Modeli birbirine yapıştırmak için gerçekten sadece bir adımdır. Yani modelde aynı yerde veri ve davranış olabilir.

Ancak bu düzenleme bile katı veri / davranış kaynaşmasını garanti etmemektedir. Yalnızca veri içeren nesneler, yalnızca mantığı içeren diğer sınıflar tarafından çalıştırılabilir ve bu, OOP'nin tamamen kabul edilebilir bir kullanımıdır.

Size özel bir örnek vereceğim. Bu biraz tartışmalı, ancak diyelim ki bir Currencynesneniz var ve bu nesnenin dolara sabitlenmiş herhangi bir para biriminde kendini temsil etme yeteneği var. Yani gibi yöntemler olurdu:

public decimal Yen { get { return // dollars to yen; } }
public decimal Sterling { get { return // dollars to sterling; } }
public decimal Euro { get { return // dollars to euro; } }

... ve bu davranış, Para birimi nesnesiyle kapsüllenir.

Ancak para bir hesaptan diğerine para transferi yapmak ya da biraz para yatırmak istersem ne olur? Bu davranış aynı zamanda Para Birimi nesnesinde de kapsanır mı? Hayır olmaz. Cüzdanınızdaki para, cüzdanınızdan banka hesabınıza geçemez; Bu parayı hesabınıza aktarmaya yardımcı olması için bir veya daha fazla acenteye (bir para çekme veya ATM) ihtiyacınız vardır.

Böylece bu davranış bir Tellernesnenin içine alınacak Currencyve Accountgirişler olarak kabul edecek ve nesneleri kabul edecektir , ancak Transactiongiriş nesnelerinin işlenmesine yardımcı olmak için belki biraz yerel durum (veya bir nesne) dışında herhangi bir veri içermeyecekti .

MVC , tekli nesnelerden çok daha yüksek bir soyutlama seviyesinde çalışır ve aslında üçünün her biri (model, görünüm ve denetleyici) tipik olarak her birinin hem veri hem de davranışa sahip olduğu birçok nesneden oluşur.

Verileri ve davranışları içine alan nesnelerin, genel olarak programlar için iyi bir temel yapı taşı olduğu, soyutlama seviyelerinin ve tüm amaçların en iyi modeli olduğu anlamına gelmez.

OOP, her birinin kendi verisine ve davranışına sahip olan nesneler arasındaki etkileşimi kısıtlamaz.

Bir karınca ve karınca kolonisi analojisini düşünün: bireysel bir karıncanın davranışı (bütün gün koşuşturma, yiyecek getirme) genel koloninin davranışından farklıdır (en çok istenen yeri bulun, daha fazla karınca yapın). MVC paterni, bir karınca kolonisinin istenen sosyal yapısını tarif ederken, OOP bireysel karıncaların tasarımını yönlendirir.

OOP ayrıca endişelerin ayrılması ile ilgilidir , yani farklı nesnelerdeki farklı rolleri / sorumlulukları ayırmaktır.

MVC bu bileşenlere ayrılır:

• Model: veri ve iş mantığı
• Görünüm: verilerin temsili
• Denetleyici: model ve görünüm arasında koordinasyon.

Dolayısıyla bu sorumluluklar açıkça belirgindir ve gerçekten de çoklu varlıklara ayrılmalıdır.

Model-View-Controller modelinde, veri ve mantık / algoritmalar sırasıyla model ve kontrolör olarak ayrı varlıklara yerleştirilir.

Model ve denetleyici iki ayrı roldür. Bir modelde hem durum hem de mantık vardır ve bir denetleyicide hem durum hem de mantık vardır. İletişim kurmaları gerçeği ikisinin de kapsüllenmesini bozmaz - denetleyici , modelin verilerini nasıl sakladığını veya denetleyici bir kısmını aldığında veya güncellediğinde verilere ne yaptığını bilmez veya önemsemez . Model, kontrol cihazının modelin sağladığı verilerle ne yaptığını bilmiyor veya umursamıyor.

Bunu şu şekilde düşünün: nesneler enkapsülasyonu bozmadan ileri ve geri veri iletemezse, gerçekten tek bir nesneye sahip olabilirsiniz!

Eşdeğer bir OOP yaklaşımında model ve kontrolör aynı mantıksal varlığa yerleştirilmemeli midir?

MVC olan bir OOP yaklaşımı - özellikle, etkili bir program organize etmek nesneleri nasıl kullanılacağına karar için bir reçete bulunuyor. Ve hayır , model ve kontrolör aynı varlık olmamalıdır. Bir denetleyici, model ve görünüm arasında ayrılmaya izin verir. Modelin ve görüşün birbirinden bağımsız tutulması, onları hem test edilebilir hem de tekrar kullanılabilir hale getirir.

MVC, nesnelerin etkileşime girmesinin mantıklı bir yolunu tanımlayan bir kalıptır; bu bir meta sınıf değildir. OO, OO varlıkların davranışlarını ve verilerini ve söz konusu varlıkların nasıl etkileşimde bulunduğunu tanımlamakla ilgilidir. Tüm sistemi büyük bir nesnede birleştirmekle ilgili değil.

Denetleyici, bir modelin davranışını temsil etmiyor. Kontrolörler tamamen bir kullanıcının yapabileceği ve bir kullanıcının görebileceği tüm uygulamanın davranışını temsil eder.

Denetleyicileri ve modelleri tek olarak görmek yanlıştır. Farklı amaçları, farklı semantikleri var ve bu nedenle tek bir nesnede birleştirilmemeleri gerekiyor.

Model katmanı, yalnızca denetleyici katmanından yalnızca veri değil, yalnızca mantıktır.

Denetleyici katmanı, amaçları doğrultusunda eksiksiz bir nesne koleksiyonuna sahip olacaktır. Görünümden girdi almak ve bu girişi modelin işleyebileceği bir forma dönüştürmek için nesneler olacaktır. Struts Java çerçevesi, Eylem / Form modelinde buna iyi bir örnektir. Form, kullanıcıdan gelen girdilerle doldurulur ve ardından Faaliyete geçirilir. Eylem bu verileri alır ve modeli işlemek için kullanır.

Aynı şekilde, Model katmanı tamamen verilerden oluşmaz. Örneğin, bir Kullanıcı nesnesini alın - bir kullanıcıyı bir veritabanından alan koda ihtiyacınız olabilir veya bir Kullanıcıyı bir Sipariş ile ilişkilendirmek veya Kullanıcı adresinin şirket hizmet alanınız içinde olduğunu doğrulamak için kod gerekebilir ... resim. Bu kontrolör mantığı değil. İş mantığıdır ve Model katmanını, iş mantığı için Servis veya Yönetici katmanları, veritabanı erişimi için bir DAO (Veritabanı Erişim Nesnesi) katmanı ve diğerleri gibi birkaç katmana bölmesine yol açar.

MVC, bireysel Model işlemlerini organize etmek için bir yöntem değildir. Bundan daha yüksek bir düzeyde çalışır - uygulamaya nasıl erişileceğini organize etmek için bir yöntemdir. Görünüm, verileri işlemek için veri ve insan eylemleri sunmak içindir, Kontrolör, kullanıcı eylemleri ve çeşitli görüşler arasında çeviri içindir ve Model, iş verilerinin ve bunun iş nedenlerinin var olduğu yerdir.

OOP'nin amacı, birbirine ait veri ve işlevleri bir araya getirmektir . Bazı verilere dayanan bir hesaplama her zaman bu verilere ait değildir .

MVC'de bir veri parçasını (görünüm) görüntüleme işlevi veriden (model) ayrı tutulur. Neden? Özellikle ekran mantığının altında yatan verileri değiştirmek zorunda kalmadan değiştirilebilmesi için. Aynı verilerin farklı bir sunumunu yapmanız gerektiğinde görünümü değiştirmeyi kolaylaştırır: veya ekran donanımının özellikleri değiştiğinde: veya Windows'tan Linux'a geçtiğinizde; veya iki kişinin aynı verilere bakmanın iki farklı yolunu bulmasını istediğinizde.

MVC, OOP ile çatışmaz - aslında Nesneye Yönelik İlkelerin doğru bir şekilde uygulanmasından kaynaklanır.

Bir model nesnesine bağlı kalıcı verileri, modelin etkileşimde bulunduğu veritabanlarındaki uygulama verileriyle karıştırdığınıza inanıyorum. Bir model, iş mantığı ve veritabanlarıyla çalışma ve işlem yapma kuralları içerir. Bugün bir satış olup olmadığı, kullanıcının VIP statüsüne hak kazanıp kazanmadığı ve ardından verilere erişme, ayarlama veya işleme zamanı geldiğinde veya bir satın alma işlemi gerçekleştirme zamanı geldiğinde buna göre şube mantığı belirleyebilir ve kontrol edebilir. Nesneleri bir dizi yöntemin kapsüllenmesi ve kalıcı değerler veya veriler açısından tartışırken bahsettiğimiz bayraklar.

Model nesnesinin hangi iş kurallarının geçerli olduğunu belirlemeye yönelik verileri tutması gibi, bir kontrolör, IMO da, kullanıcının giriş yapmış olması veya geçerli bir kredisine sahip olmaları gibi, uygulamanın nasıl davranması gerektiği ile ilgili daha genel uygulama durumu verilerini tutmalıdır kart verileri yerinde. Model metotları, bunların ilk etapta durumunu belirleyecektir, ancak işletmenin nasıl yürüdüğüne veya veri işlemlerinin gerçekleştirildiği durum için geçerli değilse denetleyicinin genel uygulama akışına uygun bayrakları tutması mantıklıdır. Giriş yapmadıklarını belirledikten sonra, başka bir giriş yapma girişimi yapılıncaya kadar modeli kullanıcı kontrolleri ile bile rahatsız etmeyin.

Aynı şekilde, çoğu sunucu tarafında web çerçevelerinde gördüğünüz daha tipik HTML şablonlarına karşı uygun bir görüntüleme nesnesiyle. Kullanıcının renk tercihleri ​​yüklendikten sonra, bu verileri tutan ve üzerinde çalışan görünüm olmalıdır. Ayarların yüklenmesi, doğrulanması ve değiştirilmesi tüm model problemleridir, ancak değişiklikler gerçekleşene kadar sadece bir kez model problemleri olmalıdır.

IMO, hiçbir şey denetleyicilerin dahili toplama nesneleri olarak görüntüleyen ve modellerini birleştiren nesneler olamayacağını söylüyor. Bu, aslında MVC'yi bir UI widget fabrikası gibi daha küçük bir ölçekte uygularsanız mantıklıdır, çünkü denetleyici, Görünümü ve Modelin nasıl etkileşime girdiğinin verilerini ve mantık ayrıntılarını gömerken bir üst seviyedeki uygulama nesnelerine bir arabirim göstermek için ideal bir yerdir. Kontrolörün gerçekten de en üst seviye nesne olduğu monolotik uygulama nesneleri için anlam ifade etmiyor.

Anladığım kadarıyla; Argüman OOP'ye karşı bileşen tabanlı mimaridir. Ve dini savaşa girmeden, ikisinin de aynı şeyi tarif ettiğini düşünüyorum; sadece farklı açılardan bakıyorum.

Örneğin, OOP / OOD'un tüm amacı, kodunuzu daha modüler ve tekrar kullanılabilir hale getirmektir. Evet?

Tam olarak bileşen tabanlı mimarinin amacı budur. Yani onlar her şeyden daha benzerler.

MVC'nin sadece OOP'nin doğal evrimi olduğunu düşünüyorum ve söylemeye cüret ediyorum; nesnelerinizi düzenlemenin, endişelerin ayrılmasının ve kodun yeniden kullanılmasının daha iyi bir yolu.

Bu partiye geç kaldım ve benimkilerden önceki tüm cevapları göz önünde bulundurarak, teklif edebileceğim çok şey olmadığını itiraf ediyorum. Fakat bana öyle geliyor ki, sorun kalıbın kendisiyle değil uygulama ile ilgili. Kendisi için MVC, herhangi bir özel metodolojiye kendisini ödünç vermez. Aslında, bir MVC düzeninde yordam yönelimli kodu kolayca düşünebilirim (bu, sizin ima ettiğim şey gibi).

Yani asıl soru şudur; MVC şablonunu kullanırken prosedür koduna daha yatkın mıyız?

(ve belki sadece biraz aşağı oy alacağım?)

Anti-değil, aynı zamanda MVC için OOP gerekli değildir.

Çünkü genellikle sınıf tarafından temsil edilen kontrolörler veri içermemektedir. Hangi saf fonksiyonların yeterli olacağı.

Verileri daha ileriye götürür ve davranışlardan ayırırsanız, örneğin, modellerin yalnızca işlevlerini (veri manipülasyonundan sorumlu olan) her çağrışında toplanan veritabanı verilerinde çalıştığını varsayalım (bunun yerine örnekte bir tür veri depolamak için) alanlar) - o zaman modeller için aynı şeyi söyleyebilirsiniz.

Daha da ileri, bir uygulamanın görüş katmanını alır ve benzer şekilde bölerseniz, aslında MVC'nin OOP ile ilgisi olmadığı sonucuna varacaksınız ve MVC uygulamasının sadece prosedür yaklaşımı kullanarak herhangi bir acı çekmeden yazması tamamen mümkündür. .

Görüşümde OOP'ların bir dezavantajı var ki (veri ve davranış) tek bir varlık olarak (Sınıf) biçimlendirildiğinden, bu uyumdan ziyade birleştirme etkisi göstermektedir. Öte yandan, MVC modelinde ... (Fasulye, DAO'lar, Diğer Mantık sınıfları) içeren, Kontrolün nasıl hareket etmesi gerektiğini belirten Kontrolör ve verinin nasıl gösterilmesi gerektiğini belirlemek için Görünümler ayrı bir şekilde verilmiştir. Buna bağlı olarak, proje hazırlamak için çok büyükse, OOP'lerin aksine karışık olmaktan ayrı bir varlık olarak kolayca yapılabilir. Problem, bölme stratejisi gibi mantıksal bir şekilde çözülür ve MVC bunu en çok takip eder.