ASP.NET MVC - kiedy SRP i DRY wydają się być w konflikcie

Question

Moje najprostsze kontrolery ASP.NET MVC 2 wykonują połączenia z moją warstwą usług i mapują modele widoków do obiektów wykorzystujących AutoMapper. Wszystko wygląda fantastycznie i nie ma powtarzającego się kodu.

Jednak, kiedy się w scenariuszach, w których mam podobny zachowanie mam problemy równoważenia Pojedyncze Responsibility Principle (SRP) z not Repeat Yourself (suchy). Przykładem może być potrzeba dodania/edycji pojazdów, w których niektóre właściwości/zachowania są wspólne, podczas gdy inne są unikalne dla określonego pojazdu.

Jeśli dążę do uzyskania naprawdę cienkich kontrolerów (w ten sposób honorując zasadę odpowiedzialności pojedynczej), kończę na powtarzaniu kodu zarówno w widokach, jak i kontrolerach z niewielkimi zmianami (tytuł, etykiety pól, widoczność pola, wartości rozwijane, kryteria wyboru itp. .).

Jeśli dążę do tego, aby nie powtarzać kodu, kończę pakowanie zbyt dużej logiki do pojedynczego kontrolera/widoku i robi się nadęty.

Jakie są sposoby adresowania powtarzanego kodu w kontrolerach/widokach? Nie mówię o kodzie bazy danych, który można obliczyć w repozytorium. Nie mówię również o logice biznesowej, którą można obliczyć na poziomie warstwy usług. Szukam narzędzi i/lub reguł, które pomogą mi stworzyć najlepsze rozwiązanie w scenariuszu opisanym powyżej.

Answer 1

Otrzymasz:

• partials
• RenderAction
• filtry Action
klas
• obsługa warstw i pomocnicze (nie HtmlHelper)
• modelu spoiwa
• kontrolerów bazowych wtryskowych
• zależność

Twoje widoki mogą wywoływać wspólne części/akcje dla podobnych części, wspólne dane można przygotować za pomocą filtrów akcji, kod dostępu do bazy danych można ukryć w inteligentnym segregatorze modelu lub możesz mieć kontroler nadrzędny, który kontrolery podrzędne zastępują określonym ulepszenia. I, oczywiście, dobre stare usługi, w których po prostu wyodrębniasz wspólny kod w pomocnicze/statyczne metody lub, lepiej, wstrzykujesz konkretne implementacje.

To nic nowego, te same stare sztuczki.

A może twoi kontrolerzy wykonują za dużo pracy? Tutaj też pomaga pomoc. ASP.NET MVC ma bardzo dobre narzędzia do ukrywania kodu warstwy infrastruktury i odsuwania go od kontrolerów. A jeśli to nie jest infrastruktura - prawdopodobnie należy do warstwy domeny. Tam możesz używać dziedziczenia, kompozycji i innych sztuczek OOP.

Konkretny przykład. Załóżmy, że twoi kontrolerzy powinni ustawić kilka właściwości w inny sposób.

1. Można mieć swoje poglądy, aby to zrobić, jeśli jest to głównie formatowania lub wybierając jakie właściwości pokazać
2. Można mieć swoje podmioty mieć metod wirtualnych - to znaczykod refaktora do przeniesienia decyzji do warstwy domeny zamiast kontrolerów
3. Możesz mieć klasy helper ViewDetails, które wezmą twoje jednostki i uzyskają dane na podstawie tego, czego potrzebujesz; to trochę brudna sztuczka, ale czasem przydatna; przekazujesz decyzję innej klasie "strategii"
4. Możesz użyć filtrów akcji, aby dodać te dane do ViewData, lub dostosować wybrane typy ViewData.Model (poszukaj jakiegoś interfejsu).
5. Można mieć streszczenie kontrolera, w którym dzieci przechodzą szczegóły implementacji do konstruktora bazowego jak(): podstawowej (repozytorium => repository.GetSpecificData())

I tak dalej. Właściwie używam ich wszystkich w odpowiednich miejscach.

Answer 2

Martwisz się zbytnio o SRP i DRY. Są to tylko zasady i nie zawsze mają rację. SRP i DRY są dobre, jeśli sprawiają, że twój kod jest łatwiejszy w utrzymaniu, ale jeśli przeszkadzają, to je ignoruj. MVC jest podobny. Jest przydatny w prostych małych aplikacjach komputerowych, ale nie jest odpowiedni dla aplikacji internetowych. Web Forms jest znacznie lepszy dla Internetu, podczas gdy MVC to coś z lat 80.

Answer 3

Zalecam stosowanie w takich przypadkach SRP zamiast DRY. Napisałem here szczegółową odpowiedź.

W skrócie oba są zasadami, które pomagają utrzymać kod w utrzymaniu. DRY to niski poziom abstrakcji, a SRP to wysoki poziom abstrakcji. Dzięki utrzymaniu aplikacji wysoka struktura poziomu abstrakcji jest ważniejsza niż niski poziom abstrakcji.

W twoim przypadku nie uważam, że należy zrezygnować z DRY.

Przykładem tego może być potrzeba dodawać/edytować pojazdów gdzie niektóre Właściwości/zachowania są współdzielone, podczas gdy inne są specyficzne dla konkretnego pojazdu.

Wiele wzorów może pomóc w tym przypadku. Możesz użyć dekoratora, kompozycji i tak dalej ... w połączeniu z budowniczymi dla różnych typów pojazdów.