MVC'de DAO, Kontrolör veya Modelden çağrılmalıdır


14

Doğrudan Controller sınıfından çağrılan DAO'ya ve Model sınıfından DAO'ya karşı çeşitli argümanlar gördüm. İçeriden DAO'yu çağırmalı ve denetleyici model sınıfını çağırmalıdır.

DAO çağrısını denetleyiciye yazarsak, bir REST hizmetinin işlevselliği yeniden kullanması mümkün olmaz mı? Her iki yaklaşımı da özetledim.

Yaklaşım # 1

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            new CustomerDAO().save(customer);

    }


 }

Yaklaşım # 2

  public class CustomerController extends HttpServlet {

    proctected void doPost(....)  {

            Customer customer = new Customer("xxxxx","23",1);
            customer.save(customer);

    }


 }

 public class Customer {

   ...........

   private void save(Customer customer){

        new CustomerDAO().save(customer);

   }

}

Not -

Model'in tanımı şu şekildedir:

Model: Model, uygulama etki alanının davranışını ve verilerini yönetir, durumu hakkında bilgi isteklerine yanıt verir (genellikle görünümden) ve durumu değiştirme yönergelerine (genellikle denetleyiciden) yanıt verir.

Olay güdümlü sistemlerde, model bilgiler değiştiğinde gözlemleyebilmeleri için (genellikle görüntüleme) gözlemcilere bildirimde bulunur.

Bu konuda uzman görüşüne ihtiyacım var çünkü birçok # 1 veya # 2 kullanarak buluyorum, Peki hangisi?


1
Kontrolör modelden her şeyi yüklemeli ve görünüme geçirmelidir.
jgauffin

2 numaralı öneri yaklaşımı mısınız?

1
"Bir denetleyici, görünümün modelin sunumunu değiştirmek için ilişkili görünümüne komutlar gönderebilir (örn., Bir belgeyi kaydırarak). Modelin durumunu güncellemek için modele komutlar gönderebilir (örn. Bir belgeyi düzenleme)." .. emm .. nerede diyor ki, o denetleyici veri çıkarıyor veya veriyi geçiriyor olmalı?
mefisto

Yanıtlar:


31

Bence, MVC deseni ile 3 katmanlı mimari arasında ayrım yapmak zorundasınız. Sonuç olarak:

3 katmanlı mimari:

  • veri: kalıcı veri;
  • hizmet: uygulamanın mantıksal kısmı;
  • sunum: hmi, webservice ...

MVC kalıbı yukarıdaki mimarinin sunum katmanında yer alır (bir web uygulaması için):

  • veri: ...;
  • hizmet: ...;
  • sunum:
    • controller: HTTP isteğini durdurur ve HTTP yanıtını döndürür;
    • model: görüntülenecek / işlenecek verileri saklar;
    • görünüm: çıktı / ekranı düzenler.

Tipik bir HTTP isteğinin yaşam döngüsü :

  1. Kullanıcı HTTP isteğini gönderir;
  2. Kontrolör bunu durdurur;
  3. Kontrolör uygun servisi çağırır;
  4. Hizmet, bazı kalıcı verileri döndüren uygun dao'yu çağırır (örneğin);
  5. Hizmet verileri ele alır ve verileri denetleyiciye döndürür;
  6. Kontrolör verileri uygun modelde saklar ve uygun görünümü çağırır;
  7. Görünüm , modelin verileriyle örneklenir ve HTTP yanıtı olarak döndürülür.

1
Ne diyoruz "Tipik bir HTTP isteğinin yaşam döngüsü" MVC değil. Ve DAO sadece etki alanı mantığı ile kalıcılık arasındaki etkileşimi / çeviriyi kolaylaştıran bir nesnedir. Öyle DEĞİL aktif kayıt için farklı bir isim. Ayrıca .. model sunumun bir parçası haline geldiğinden beri ?!
mefisto

1
@teresko 1) Evet, MVC, ancak 3 katmanlı bir mimari içinde. Değilse, neden? 2) Haklıydın, ben düzenledim. 3) Tüm MVC modeli sunum katmanında yer aldığından. Tipik örnek: Modelleri yalnızca anahtar / değer çiftlerini içeren Haritalar olan Spring MVC. SpringFuse bu seçimi de yaptı.
sp00m

2
Burada @ sp00m ile anlaşmak zorundayım ... Tipik bir HTTP isteğinin açıklaması bir MVC web uygulaması için doğrudur ve Modelin (MVC'de 'M' olarak) sunum katmanının bir parçası olarak konumlandırılması da doğrudur . N katmanlı MVC uygulamalarında, 'Model' tipik olarak aşağıdaki katmanların geri kalanında sunum katmanının cephesidir.
Eric King

8

Model katmanından.

Daha kesin olmak gerekirse: model katmanında bulunan hizmetlerden, çünkü etki alanı nesneleri ve depolama mantığı soyutlamaları arasındaki etkileşimi yönetirler.

Kontrolör yalnızca model katmanının durumunun değiştirilmesinden sorumlu olmalıdır. DAO'lar kalıcılık mekanizmasının bir parçasıdır. Bu, etki alanı iş ve uygulama mantığının bir parçasını oluşturur. Denetleyicideki DAO'larla etkileşime girmeye başlarsanız, sunum katmanındaki etki alanı mantığını sızdırırsınız .


Hizmet katmanı kullanmak için DDD kalıbı olmalı mı? Yanlışsam düzelt. MVC'de hizmet katmanımız var mı?

Alabilirsin. Hizmetler, etki alanı mantığını uygulama mantığından ayırmak için kullanılır. Bu gerekli hale gelir, sonra saf CRUD etki alanı yapılarından (etkin kayıt), depolama mantığını etki alanı mantığından ayıran bir şeye taşırsınız. Tamamen gerçekleştirilmiş model katmanında 3 mantıksal ayırım vardır: kalıcılık, etki alanı ve uygulama.
mefisto

3

Resmi MVC modelinin ne istediğinden emin değilim, ancak normalde kontrolörler ve DAO'lar arasında bir "hizmet" katmanı olmasını seviyorum. Denetleyici verileri istekten alır ve uygun hizmet sınıfına iletir. Hizmet sınıfı, model sınıflarını geçen bir veya daha fazla DAO'yu çağırmaktan sorumludur. Bu model sınıfları daha sonra görünüm katmanına gönderilmek üzere denetleyiciye geri gönderilir. Birden çok denetleyici aynı hizmet katmanı yöntemlerini kullanabileceğinden hizmet katmanını yeniden kullanmak yardımcı olur.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.