Bir kontrolör çok fazla yağlanırsa ve model somutlaştırması toplanmaya başlarsa, bir servis katmanı kullanılabilir.
Eğer mantığı bir servis sınıfının içine sararsam, bir / iki yöntemle bir grup Hizmet alırım. Bu bir kod kokusu gibi geliyor. Bununla ilgili en iyi uygulamalar var mı?
Bir hizmet modelleri başlatabilir mi?
Bir hizmet modelleri başlatırsa, hizmetler birim sınanamaz. Sadece entegrasyon testleri ile kapsanabilir mi?
Yanıtlar:
'SOLID'de' I ', Arayüz Ayrımı anlamına gelir. Bu ilkenin fikri, büyük arayüzleri daha modüler olan daha küçük arayüzlere ayırmaktır. MVC hizmetinde normalde kontrolörün güvendiği bir arayüz bulunur. Denetçilerinizin bu hizmetin somut uygulaması hakkında bilgi sahibi olmasını istemezsiniz. Bu nedenle, bir veya iki yöntemle bir grup hizmetin olması iyi bir şeydir.
Hizmetler normalde büyük uygulamalardaki DTO'ları veya doğrudan küçük uygulamalardaki etki alanı modellerini döndürür. DTO'lar normalde daha fazla iş anlamına gelir, ancak endişelerin daha iyi ayrılması anlamına gelir. Tipik akış:
Haritalama manuel olarak yapılabilir, ancak çoğu geliştirici Automapper gibi otomatik haritalama çerçevesini kullanmayı tercih eder, çünkü sıhhi tesisat kodu yazmayı sevmiyoruz ve oldukça tembel olabiliriz :-)
http://en.wikipedia.org/wiki/Interface_segregation_principle
https://github.com/AutoMapper/AutoMapper
DTO'ların ve alan adı modellerinin kullanımına ilişkin yığın akışı hakkında birçok tartışmadan biri: /programming/2680071/dto-or-domain-model-object-in-the-view-layer
MVC'de Model, sadece bir DTO veya bir dizi Yönetici / Hizmet değil, uygulamanızın modellediği kavramları temsil etmeyi amaçlamaktadır. Bunu, alanın tamamı veya eyalet ve davranışlar da dahil olmak üzere iş mantığı olarak düşünebilirsiniz. Şimdi, kontrolörün amacının biraz daha net hale geldiğini bildiğimiz göz önüne alındığında. İşi sadece komutları Model'e ve sonucu tekrar görünümlere çevirmektir. Bu genellikle farklı ancak MVC'deki Model ile karıştırılan ViewModels şeklinde yapılır.
Eğer iyi tanımlanmış bir Modeliniz yoksa, o zaman mantığın çoğunun Kontrolörlerin kendisinde olduğu noktaya gelmiş olabilirsiniz. Bu noktada, denetleyicilerinizin boyutunu azaltmaya başlamak için bu mantığı yönetici veya hizmet nesnelerine geri çekmeye başlayabilirsiniz. Bu hizmetler genellikle DTO / Entity benzeri nesneler üzerinde geri döner ve çalışır. Ardından denetleyici, bu hizmetler ve Görünüm Modelleri arasındaki eşleme katmanı haline gelir. Eşlemeyle ilgili birkaç ipucu için bu makaleye göz atın Arkadaşlar, arkadaşlarınızın AutoMapper kullanmasına izin vermez .
Sorularınıza gelince, ilki uygulamalarınıza çok bağlıdır. Mantık denetleyicilerinizden kaldırıldıktan sonra daha belirgin hale gelmesi gereken yol boyunca yeniden düzenleme yapmanız gerekecektir. Testlere gelince, hizmetlerin içinde örnek teşkil eden problemler yoktur, ancak testlerin zor olduğunu düşünüyorsanız, muhtemelen sadece her biri tek bir sorumlulukla hizmeti daha küçük parçalara bölmeniz gerekir.
Denetleyiciler yalnızca modele (iş mantığının gerçekleştiği yer) çağrılar içermeli ve bu çağrılara dayanarak görünüm için veri atamalıdır (bilgi nesneleri veya hata mesajları), bu nedenle denetleyici hala çok karmaşık bir sayfa için bile oldukça küçük olacaktır. çok büyür belki o sayfanın daha fazla sayfaya genişletilmesi gerektiğini düşünmelisiniz.
Yine de model oldukça büyük olabilir ... Bulduğum çözüm denetleyicinin içinde hangi modelin yükleneceğini söyleyen bir değişkene sahipti ve belirli görevler için belirli modeli yükledim.
Model-view-controller modeline şu şekilde temiz uymaya çalışın:
Birden fazla denetleyici tarafından gerçekleştirilmesi gerekebilecek veya denetleyicinin bir parçası olmak için yeterince spesifik olmayan mantık gerçekleştirmek için hizmetleri gerçekten yararlı buluyorum. .
"Model (iş mantığının gerçekleştiği yer)" dediğinde kişisel olarak 'aaa' ile aynı fikirde değilim. yine hizmetler veri soyutlama görevine dahil edilmemelidir ...
sadece yo demek ....