Architektura MVC + WCF + TDD lub DDD

Question

Tutaj znów jesteśmy na rozdrożu.

Chcę spróbować wdrożyć, przynajmniej na najbliższe 3 lata, prosty, sprawdzony sposób na projektowanie aplikacji. Za każdym razem, gdy zaczynam projekt, wydaje mi się, że to po raz pierwszy z powodu przytłaczającej liczby "sposobów" tworzenia stron internetowych w tych dniach.

Mam ten przykładowy kod, który dostałem z tego pakietu Kupiłem połączenie Design Pattern Framework 4 C#. Wśród wielu projektów, które posiadają, jest jeden, który nazywa się Wzorcami projektu w działaniu. Możesz go pobrać stąd: https://skydrive.live.com/redir?resid=B853B0DB724C30E5!16735&authkey=!AOeHSAWa_P4vzzU

Moje pytanie, po spojrzeniu na to rozwiązanie, Co jest dobre, złe, co byś zatrzymał, co byś usunął, co jest niepotrzebne itp. Na temat tego przykładu?

Rozumiem, że próbują pokazać wielu klientów, a także wielu DAO. Ale ogólnie rzecz biorąc, czy ta architektura byłaby jedną z tych "szablonów"? Dzięki.

Answer 1

Moje pytanie, po spojrzeniu na to rozwiązanie, Co jest dobre, złe, co byś zatrzymał, co byś usunął, co jest niepotrzebne, itp. itd. Na temat tego przykładu?

Po szybkim spojrzeniem, oto co powiedziałbym:

• W odniesieniu do znacznika DDD na swoje pytanie, to oczywiście nie jest domena Driven Architecture. Obiekty biznesowe wyglądają na anemic oprócz kilku prostych reguł sprawdzania poprawności i wiele podstawowych bloków architektury DDD nie istnieje (agregaty, obiekty wartości itp.).

• O ile nie przeoczyłem czegoś, większość operacji biznesowych są operacjami CRUD, które nie są tak naprawdę reprezentatywne dla rzeczywistej aplikacji korporacyjnej.

• Istnieje gruba warstwa usługi z grubą klasą ActionService, która zasadniczo wydaje się obsługiwać wszystkie przypadki użycia aplikacji. Dobrą wiadomością jest to, że zajmuje się przypadkami zastosowań w sposób agnostyczny (o ile wiem, obiekty typu Request and Response, którymi manipuluje, są niezależnymi mechanizmami dostarczania). Bycie grubym jest mniej pożądane, ponieważ klasa zawiera zbyt wiele obowiązków (SRP).

• Używanie repozytoriów po stronie klienta i DAO po stronie serwera wydaje się dziwne, ale dlaczego nie.

• Jeśli jest naprawdę oparty na testach, dlaczego nie uwzględnić wszystkich testów jednostkowych zamiast tylko jednej próbki?

Oprócz tego, warstwy są dobrze zaprojektowane i, jak pokazują liczne warstwy prezentacji, to nie powinno być trudne, aby zastąpić jeden front-end dla drugiego lub jeden trwałego magazynu dla drugiego.

Answer 2

Architektura systemu jest bardzo podobny do architektury budynku:

• Nie ma jednego „prawo” sposób
• Każdy ma swoje zdanie na temat „najlepsze”
• „Najlepsze” architektura zależy od kontekst i musi
• style i metody zmieniają się w czasie

Istnieje wiele czynników, które go do choosi ng an architecture:

• Czas na rynek - jak długo trzeba coś robić?
• Łatwość utrzymania - czy tylko Ty będziesz go obsługiwać? Otwarte źródło?
• Rozszerzalność - czy będzie to system zamknięty czy otwarty?
• Skalowalność - proste narzędzie lub skala przedsiębiorstwa?
• Platforma - internetowa czy natywna? Komputer stacjonarny lub komórkowy?

Wszystko, co powiem, zdziwiłbym się, gdyby udało Ci się opracować kompletne ramy, które pasują do każdego projektu, który będziesz mieć przez następne 3 lata. Pomyśl o MVC, WFC, TDD, DDD, itp. Jako o narzędziach, których możesz użyć do zbudowania systemu, który spełnia potrzeby tej sytuacji.

Moja opinia brzmi: użyjcie wszelkich pojęć, które możecie zrozumieć (i mogą uczyć innych, jeśli to konieczne), o ile pasują one do konkretnej sytuacji.

Answer 3

1. Wybierz jedną.
2. Wypróbuj.
3. Refaktor/zmiana, jeśli nie jest odpowiednia dla Ciebie.

Przede wszystkim upewnij się, że używasz wzorników, które można refodować.Jeśli korzystasz z TDD i odkryjesz, że możesz wstrzykiwać swoje zależności, podróbki itp., To ułatwi to proces refaktoryzacji. Trzy lata to długi czas na wykorzystanie dowolnego wzoru. Znajomy powiedział, że jeśli nie patrzysz na kod z 6 miesięcy i myślisz, że jest do bani, może nie nauczysz się wystarczająco:)