w schemacie projektowym MVC/MVP/MVPC gdzie umieścisz swoją logikę biznesową? Nie, nie mam na myśli ASP.NET MVC Framework (inaczej "Tag Soup").w MVC/MVP/MVPC gdzie umieścisz swoją logikę biznesową?
Niektórzy mówią, że powinieneś umieścić go w "Kontroli" w MVC/MVPC lub "Prezenter". Ale inni uważają, że powinno to być częścią Modelu.
Co sądzisz i dlaczego?
To jak ja to widzę:
Sterownik jest dla logiki aplikacji; logika, która jest specyficzna dla sposobu, w jaki aplikacja chce wchodzić w interakcję z dziedziną wiedzy, której dotyczy.
Model dotyczy logiki niezależnej od aplikacji. tj. logika, która jest ważna we wszystkich możliwych zastosowaniach domeny wiedzy, której dotyczy.
Dlatego prawie wszystkie reguły biznesowe będą w modelu.
Znajduję przydatne pytanie, aby zadać sobie pytanie, kiedy muszę zdecydować, gdzie umieścić logikę: "czy to zawsze prawda, czy tylko część aplikacji, którą obecnie koduję?"
+1: Interfejs użytkownika to View/Controller - zmienia się. Model to esencja. –
Myślę, że to dobrze. –
Nie sądzę, że należy do kontrolera, ponieważ po jego osadzeniu nie może się wydostać.
Myślę, że MVC powinna mieć kolejną warstwę, która jest wstrzyknięta pomiędzy: warstwę usługi, która odwzorowuje przypadki użycia. Zawiera logikę biznesową, wie o jednostkach pracy i transakcjach oraz zajmuje się obiektami modelu i trwałości w celu wykonania swoich zadań.
Sterownik ma odniesienie do usługi, która musi spełnić jego przypadek użycia. Niepokoi się tym, że nie wysyła żadnych próśb do obiektów, z którymi może sobie poradzić, wywołuje usługę i marszałków, by wysłać odpowiedź.
Przy takim ustawieniu usługa może być użyta sama, nawet bez pary kontrolera/podglądu. Może to być obiekt lokalny lub zdalny, pakowany i wdrażany w dowolny sposób, z którym kontroler się obsługuje.
Kontroler staje się teraz bardziej związany z widokiem. W końcu kontroler, którego użyjesz na pulpicie, prawdopodobnie będzie inny niż ten, który ma aplikacja internetowa.
Myślę, że ten wzór jest bardziej zorientowany na usługi.
Możesz umieścić go w dwóch miejscach. Kontroler i warstwa prezentacji. Mając część logiki w warstwie Prezentacja, można ograniczyć liczbę żądań z powrotem do architektury, która dodaje obciążenie do systemu. Tak, musisz dwa razy kodować, ale czasami jest to potrzebne, abyś czuł się komfortowo.
Jakbym to, co zostało tu powiedziane (http://www.martinhunter.co.nz/articles/MVPC.pdf)
„Z MVPC składnik prezenter modelu MVP jest podzielony na dwie elementów: (logicznych widok kontrola) prezenter i kontrolera (logiki sterującej streszczenie przeznaczenia). "
Widzę, że PDF jako "wymuszony" i sztuczny na podziale prezentera i logiki kontrolera w podanym przykładzie. uważam, że wyjaśnienie podane w http://aviadezra.blogspot.com/2008/06/mvpc-model-view-presenter-controller.html jest bardziej odpowiednie w przypadku, gdy delegaci podglądu kontrolują bezpośrednio prezentera, a zmiany GUI dotyczące akcji wykonywane są enkapsulowane w "metodach zmiany interfejsu użytkownika" i wywoływane po wykonaniu działania. – zappan
FYI Przenieśliłem artykuł tutaj wymieniony https://www.continuity.kiwi.nz/Content/Articles/MVPC.pdf Pozdrawiam Martina. – muszeo
Sposób, w jaki mam swoją ASP.NET struktura aplikacji MVC przepływ pracy wygląda następująco:
Controller -> USŁUGI -> Przechowalnie
Warstwa powyżej usługi jest miejsce, gdzie cała logika biznesowa odbywa. Jeśli umieścisz logikę biznesową w warstwie kontrolera, stracisz możliwość ponownego użycia logiki biznesowej w innych kontrolerach.
Chciałbym móc głosować na to więcej ... Robię to samo. – Martin
@Kevin Kiedy mówisz "warstwy usług", czy dosłownie masz na myśli SOA jak w czymś takim jak WCF/usługi danych/itd.? Czy jest zaimplementowany jako więcej kodu/klas, które znajdują się pomiędzy kontrolerem a repozytorium? – AaronLS
@AaronLS Mam na myśli kolejny projekt, który znajduje się pomiędzy kontrolerem a repozytorium. –
Na litość boską, włóż ją do modelu !!!!!
Oczywiście część interakcji użytkownika musi być w widoku, co będzie związane z Twoją aplikacją i logiką biznesową, ale unikaj tego w jak największym stopniu. Ironicznie podążając za zasadą robienia jak najmniejszej ilości czynności, ponieważ użytkownik "pracuje" w twoim GUI i tak samo podczas "przesyłania" lub żądań akcji sprawia, że użytkownik jest bardziej przyjazny dla użytkownika i użyteczny, a nie na odwrót. Przynajmniej dla aplikacji biznesowych.
Umieść swoją logikę biznesową w domenie i zachowaj swoją domenę separte. Preferowałem Presenter -> Command (polecenie Message use NServiceBus) -> Domain (z kontekstem ograniczonym BC) -> EventStore -> Event handler -> Repository (read model). Jeśli logika nie pasuje do domeny, użyj warstwy usługi.
Przeczytaj artykuł Martina Fowlera, Erica Evana, Grega Younga i Udiego Dahana. Zdefiniowali bardzo jasny obraz.
Tutaj jest artykuł napisany przez Marka Nijhof: http://elegantcode.com/2009/11/11/cqrs-la-greg-young/
+1 za świetny artykuł –
Link do artykułu już nie istnieje. – Celdor
@Celdor użyj web.archive.org - https://web.archive.org/web/20100124174150/http://elegantcode.com:80/2009/11/11/cqrs-la-greg-young/ –
Moim zdaniem Twoje pytanie jest trochę brakuje kontekstu. Masz na myśli MVC jako wzorzec aplikacji lub wzorzec interfejsu użytkownika? – Rookian