MVC'de iş mantığı [kapalı]
Yanıtlar:
İş kuralları modele girer.
Bir posta listesi için e-posta görüntülediğinizi varsayalım. Kullanıcı, e-postalardan birinin yanındaki "sil" düğmesini tıklar, denetleyici modeli N girişini sileceğini bildirir, ardından modelin değiştiği görünümü bildirir.
Belki de yöneticinin e-postası asla listeden kaldırılmamalıdır. Bu bir iş kuralıdır, bu bilgi modele aittir. Görünüm sonuçta bu kuralı bir şekilde temsil edebilir - belki de model, iş kuralının bir fonksiyonu olan bir "IsDeletable" özelliğini ortaya koyar, böylece görünümdeki sil düğmesi belirli girişler için devre dışı bırakılır - ancak kuralın kendisi dahil değildir görünümde.
Model sonuçta verileriniz için ağ geçidi denetleyicisidir. Kullanıcı arayüzüne hiç dokunmadan iş mantığınızı test edebilmeniz gerekir.
Her şeyden önce:
MVC desenini ve n katmanlı tabanlı tasarım ilkelerini karıştırdığınıza inanıyorum.
Bir MVC yaklaşımı kullanmak, uygulamanızı katmanlamamanız gerektiği anlamına gelmez.
MVC'yi daha çok sunum katmanının bir uzantısı gibi görürseniz yardımcı olabilir.
MVC modelinin içine sunum dışı kod koyarsanız, çok yakında karmaşık bir tasarım elde edebilirsiniz.
Bu nedenle iş mantığınızı ayrı bir iş katmanına koymanızı öneririm.
Şuna bir bakın:
Çok katmanlı mimari hakkında Wikipedia makalesi
diyor ki:
Bugün, MVC ve benzer model-görünüm-sunucu (MVP), daha büyük bir sistemin sunum katmanına özel olarak uygulanan Endişelerin Ayrılması tasarım kalıplarıdır .
Her neyse ... bir kurumsal web uygulaması hakkında konuşurken , kullanıcı arayüzünden iş mantığı katmanına yapılan çağrılar (sunum) denetleyicisinin içine yerleştirilmelidir.
Bunun nedeni, denetleyicinin belirli bir kaynağa yapılan aramaları işlemesi, iş mantığına çağrı yaparak verileri sorgular ve verileri (model) uygun görünüme bağlar.
Mud size iş kurallarının modele girdiğini söyledi.
Bu da doğrudur, ancak (sunum) modelini (MVC'de 'M') ve katman tabanlı bir uygulama tasarımının veri katmanı modelini karıştırmıştır.
Bu nedenle, veritabanınızla ilgili iş kurallarınızı uygulamanızın modeline (veri katmanı) yerleştirmek geçerlidir.
Ancak, bunları yalnızca belirli bir kullanıcı arayüzü için geçerli olduğundan, bunları MVC yapılandırılmış sunum katmanınızın modeline yerleştirmemelisiniz.
Bu teknik, etki alanına dayalı bir tasarım veya işlem komut dosyası tabanlı bir yaklaşım kullanıp kullanmadığınızdan bağımsızdır.
Bunu sizin için görselleştireyim:
Sunum katmanı: Model - Görünüm - Denetleyici
İş katmanı: Alan adı mantığı - Uygulama mantığı
Veri katmanı: Veri havuzları - Veri erişim katmanı
Yukarıda gördüğünüz model, MVC, DDD ve veritabanından bağımsız bir veri katmanı kullanan bir uygulamanız olduğu anlamına gelir.
Bu, daha büyük bir kurumsal web uygulaması tasarlamak için yaygın bir yaklaşımdır.
Ancak basit bir DDD olmayan iş katmanı (etki alanı mantığı olmayan bir iş katmanı) ve doğrudan belirli bir veritabanına yazan basit bir veri katmanı kullanmak için küçültebilirsiniz.
Hatta tüm veri katmanını bırakabilir ve veritabanına doğrudan iş katmanından erişebilirsiniz, ancak bunu önermiyorum.
Bu hile ... Umarım bu yardımcı olur ...
[Not:] Ayrıca, günümüzde bir uygulamada birden fazla "model" olduğu gerçeğinin farkında olmalısınız. Genel olarak, bir uygulamanın her katmanının kendi modeli vardır. Sunum katmanının modeli görünüme özgüdür, ancak genellikle kullanılan denetimlerden bağımsızdır. İş katmanı ayrıca "etki alanı modeli" adı verilen bir modele sahip olabilir. Bu genellikle etki alanına dayalı bir yaklaşım benimsemeye karar verdiğinizde geçerlidir. Bu "etki alanı modeli", verilerin yanı sıra iş mantığını (programınızın ana mantığı) içerir ve genellikle sunum katmanından bağımsızdır. Sunum katmanı, veri katmanındaki verileri okumak veya veri katmanına veri yazmak için genellikle iş katmanını belirli bir "olayda" (basılan düğme vb.) Çağırır. Veri katmanı, genellikle veritabanıyla ilgili olan kendi modeline sahip olabilir.
Soru şudur: MVC konseptine nasıl uyuyor?
Cevap -> Olmaz!
Şey - öyle, ama tamamen değil.
Çünkü MVC, 1970'lerin sonlarında Smalltalk-80 programlama dili için geliştirilmiş bir yaklaşımdır. O zaman GUI'ler ve kişisel bilgisayarlar oldukça nadirdi ve dünya çapında web bile icat edilmedi! Bugünün programlama dillerinin ve IDE'lerin çoğu 1990'larda geliştirilmiştir. O zaman bilgisayarlar ve kullanıcı arayüzleri 1970'lerden tamamen farklıydı.
MVC hakkında konuşurken bunu aklınızda bulundurmalısınız.
Martin Fowler, MVC, MVP ve bugünün GUI'leri hakkında çok iyi bir makale yazdı.
İş mantığı terimi bence kesin bir tanım değil. Evans, Domain Driven Design adlı kitabında iki tür iş mantığı hakkında konuşuyor:
- Etki alanı mantığı.
- Uygulama mantığı.
Bu ayrım bence çok daha açık. Farklı türlerde iş kurallarının olduğunun farkına varılması, hepsinin mutlaka aynı yere gitmediğinin farkına varır.
Etki alanı mantığı, gerçek etki alanına karşılık gelen mantıktır. Bir muhasebe uygulaması oluşturuyorsanız, etki alanı kuralları, hesaplar, kayıtlar, vergilendirme vb. vb.
Bu iki uygulama türü için de CSV içe / dışa aktarma alakalı olabilir, ancak CSV içe / dışa aktarma kurallarının gerçek alanla hiçbir ilgisi yoktur. Bu tür bir mantık uygulama mantığıdır.
Etki alanı mantığı kesinlikle model katmanına girer. Model ayrıca DDD'deki etki alanı katmanına da karşılık gelir.
Ancak uygulama mantığının model katmanına yerleştirilmesi zorunlu değildir. Bu doğrudan denetleyicilere yerleştirilebilir veya bu kuralları barındıran ayrı bir uygulama katmanı oluşturabilirsiniz. Bu durumda en mantıklı olan gerçek uygulamaya bağlıdır.
A1 : İş Mantığı gider Modelkısmen MVC. Rolü Modelveri ve iş mantığını içermektir. ControllerÖte yandan kullanıcı girişi almak ve ne yapılacağına karar vermekle sorumludur.
A2 : A Business Rulebir parçasıdır Business Logic. Bir has ailişkileri var. Business Logicvardır Business Rules.
Bir göz atın Wikipedia entry for MVC. MVCDesen akışından bahsettiği Genel Bakış'a gidin .
Ayrıca bak Wikipedia entry for Business Logic. O bahsedilen Business Logicoluşur Business Rulesve Workflow.
Birkaç cevabın işaret ettiği gibi, çok katmanlı ve MVC mimarisinin bazı yanlış anlaşılmaları olduğuna inanıyorum.
Çok katmanlı mimari, uygulamanızı katmanlara / katmanlara ayırmayı içerir (örn. Sunum, iş mantığı, veri erişimi)
MVC, bir uygulamanın sunum katmanı için mimari bir stildir. Önemsiz uygulamalar için iş mantığı / iş kuralları / veri erişimi doğrudan Modellere, Görünümlere veya Denetleyicilere yerleştirilmemelidir. Bunu yapmak, iş mantığınızı sunum katmanınıza yerleştirmek ve böylece kodunuzun yeniden kullanımını ve sürdürülebilirliğini azaltmak olacaktır.
Model, iş mantığını yerleştirmek için çok makul bir seçimdir, ancak daha iyi / daha sürdürülebilir bir yaklaşım, sunum katmanınızı iş mantığı katmanınızdan ayırmak ve bir iş mantığı katmanı oluşturmak ve gerektiğinde iş mantığı katmanını modellerinizden çağırmaktır. İş mantığı katmanı da veri erişim katmanına çağrılacaktır.
Özellikle uygulama birden çok katman kullanarak mimar değildi, MVC bileşenlerinden birinde iş mantığı ve veri erişimini karıştıran kod bulmak nadir değildir belirtmek istiyorum. Ancak, çoğu kurumsal uygulamada, sunum katmanı içinde bir MVC mimarisi bulunan çok katmanlı mimariler yaygın olarak bulunur.
Bu cevaplanan bir soru, ama benim "bir kuruş" u vereceğim:
İş kuralları modele aittir. "Model" her zaman şunlardan oluşur (mantıksal veya fiziksel olarak ayrılmış):
- sunum modeli - görünümde kullanıma uygun sınıflar kümesi (belirli kullanıcı arayüzüne / sunuma göre düzenlenmiştir),
- alan modeli - modelin kullanıcı arayüzünden bağımsız kısmı ve
- veri havuzu - "model" in depolamaya duyarlı kısmı.
Etki alanı modelinde bulunan iş kuralları, "sunu" modeline sunuya uygun bir biçimde gösterilir ve bazen "veri katmanında" çoğaltılır (veya uygulanır).
Bir MVC projesi için iş katmanınızı Model'e koymak mantıklı değildir.
Patronunuzun sunum katmanını başka bir şeye değiştirmeye karar verdiğini söyleyin, mahvolursunuz! İş katmanı ayrı bir montaj olmalıdır. Bir Model, görüntülenecek görünüme geçen iş katmanından gelen verileri içerir. Daha sonra örneğin, modelde, iş katmanında bulunan ve PersonBusiness.SavePerson (p) öğesini çağıran bir Person sınıfına bağlanır; burada p, Person sınıfıdır. İşte ne (BusinessError sınıfı eksik ama BusinessLayer de gitmek istiyorum):
S1:
İş mantığı iki kategoride ele alınabilir:
Bir e-posta adresindeki kontroller (benzersizlik, kısıtlamalar vb.), Fatura için bir ürünün fiyatını alma veya shoppingCart'ın ürün nesnelerine göre toplam fiyatını hesaplama gibi alan adı mantığı.
Öğrencinin kayıt sürecini kontrol etmek gibi iş süreçleri olarak adlandırılan daha geniş ve karmaşık iş akışları (genellikle birkaç adım içerir ve farklı kontroller gerektirir ve daha karmaşık kısıtlamaları vardır).
İlk kategori gider modeli ve ikinci bir aittir denetleyici . Bunun nedeni, ikinci kategorideki vakaların geniş uygulama mantığı olması ve bunları modele yerleştirmenin modelin soyutlamasını karıştırabilmesidir (örneğin, ilgili kararları bir model sınıfına veya diğerine koymamız gerekip gerekmediği açık değildir. ikisine de!).
Bu Bkz cevabı modeli ve denetleyici arasında belirli bir ayrım için, bu bağlantıyı çok kesin tanımları için ve de bu bağlantıyı güzel Android örneğin.
Mesele şu ki, yukarıdaki "Çamur" ve "Frank" ile belirtilen notlar hem "Pete" ler kadar doğru olabilir (iş mantığı, iş mantığının türüne göre modele veya denetleyiciye konabilir).
Son olarak, MVC'nin bağlamdan içeriğe değiştiğine dikkat edin. Örneğin, Android uygulamalarında, web tabanlı olanlardan farklı bazı alternatif tanımlar önerilmektedir ( örneğin, bu gönderiye bakın ).
S2:
İş mantığı daha geneldir ve (yukarıda belirtilen "desiklon" olarak) bunlar arasında aşağıdaki ilişkiye sahibiz:
iş kuralları ⊂ iş mantığı
Neden bir hizmet katmanı sunmuyorsunuz? denetleyiciniz yalın ve daha okunabilir olacak, daha sonra tüm denetleyici işlevleriniz saf eylemler olacaktır. hizmet katmanında ihtiyacınız olduğu kadar iş mantığını ayrıştırabilirsiniz. kod yeniden kullanılabilirliği yükseklik. modeller ve depolar üzerinde hiçbir etkisi yoktur.
Model = CRUD veritabanı işlemleri için kod.
Denetleyici = kullanıcı eylemlerine yanıt verir ve kullanıcının bir kuruluşa özgü iş kurallarına tabi olarak, veri alma veya silme / güncelleme isteklerini modele iletir. Bu iş kuralları yardımcı sınıflarda veya çok karmaşık değilse doğrudan denetleyici eylemlerinde uygulanabilir. Kontrolör nihayet görünümden kullanıcıya yeni bir ekran veya 'güncellenmiş, teşekkürler' vb. Şeklinde bir mesaj vermek için kendisini güncellemesini ister.
View = modeldeki bir sorguya dayalı olarak oluşturulan kullanıcı arayüzü.
İş kurallarının nereye gitmesi gerektiğine dair zor ve hızlı kurallar yoktur. Bazı tasarımlarda modele girerken, bazılarında kontrolöre dahil edilirler. Ama onları kontrol cihazında tutmanın daha iyi olduğunu düşünüyorum. Modelin yalnızca veritabanı bağlantısı konusunda endişelenmesine izin verin.