MVC/MVP/MVVM - jak organizować logikę biznesową

Question

Ten wpis jest podobny do in MVC/MVP/MVPC where do you put your business logic?, ale szukam więcej szczegółów. Kupiłem model jako miejsce, w którym powinna mieszkać większość logiki biznesowej. Jednak model, o ile rozumiem, ma wiele rzeczy wewnątrz: zarządzanie stanem aplikacji, utrwalanie danych, repozytoriami, obiektami transferu danych i prawdopodobnie innymi rzeczami.

Mam aplikację, która ma bardzo złożone reguły biznesowe. Gdy użytkownik próbuje wykonać jedno określone działanie w widoku, istnieje około 20 różnych reguł, które muszą sprawdzić, czy dana akcja powinna być dozwolona, ​​lub czy użytkownik musi zostać poproszony o dodatkowe informacje. Chciałbym zakodować te zasady biznesowe za pomocą jednej metody, aby wspierać testowalność i dokumentację. Czy te reguły powinny należeć do klasy repozytoriów? Może w warstwie usług nad repozytoriami? Jaka jest najlepsza praktyka, pamiętając o tym, że używam rozwiązania ORM, takiego jak Linq, do SQL, EF lub nHibernate?

Answer 1

Jeśli są to reguły biznesowe, umieściłbym je w tabeli bazy danych, aby można było je łatwo zmienić.

Sam kod jest wtedy głupi biznes i nie dba o treść reguł, tylko strukturę kontenera reguł.

Jeśli chodzi o twoje komentarze poniżej, jeśli chcesz ograniczyć swoje podejście do kodu zorientowanego na kod z jakiegoś innego powodu, to dobrze, po prostu sprawia, że ​​opracowanie projektu znacznie droższe.

Im bardziej złożone są reguły, tym bardziej korzystasz z kierowania tabelami zamiast kodowania na sztywno. Trudno jest wymyślić model reguł, jeśli nie jesteś do tego przyzwyczajony. Po zbudowaniu modelu rozwój jest prosty.

Answer 2

Po pierwsze, nie zapominaj, że w MVP masz możliwość utrzymywania stanu w Widoku, więc jest to jedna z mniejszych rzeczy, które dzieje się w Modelu.

Może mieć zastosowanie zarówno podejście do repozytorium, jak i warstwy usługi. Myślę, że byłbym skłonny zbadać obie równolegle, używając kilku testowych aplikacji. Kiedy jedziesz, prawdopodobnie poczujesz, że jeden jest bardziej odpowiedni od drugiego, w którym to momencie możesz skoncentrować się na właściwym podejściu.

To może brzmieć jak zmarnowany wysiłek, ale będzie to znacznie mniej niż próba zmiany podejścia, gdy rozwój zacznie się na serio.

Answer 3

zaglądając w jaki CSLA.NET obsługuje reguł biznesowych może być interesujące: http://www.lhotka.net/cslanet/