Napisałem portal ASP.NET WebForms dla klienta. Projekt ewoluował, a nie był właściwie planowany i konstruowany od samego początku. W rezultacie cały kod jest zgrupowany w ramach tego samego projektu i bez żadnych warstw. Klient jest teraz zadowolony z tej funkcjonalności, dlatego chciałbym zmienić kod tak, aby był pewny, że wydam projekt. Ponieważ wydaje się, że istnieje wiele różnych sposobów projektowania architektury, chciałbym uzyskać opinie na temat najlepszego podejścia.
FUNKCJONALNOŚĆ
Portal pozwala administratorom konfigurować szablony HTML. Inni powiązani „partnerzy” będą mogli wyświetlać te szablony, dodając kod IFrame do swojej witryny. W ramach tych szablonów klienci mogą rejestrować i kupować produkty. Interfejs API został zaimplementowany przy użyciu WCF, umożliwiając zewnętrznym firmom również komunikację z systemem. Sekcja administracyjna umożliwia administratorom konfigurowanie różnych funkcji i przeglądanie raportów dla każdego partnera. System wysyła faktury i powiadomienia e-mail do klientów.
AKTUALNA ARCHITEKTURA
Obecnie używa EF4 do odczytu / zapisu do bazy danych. Obiekty EF są używane bezpośrednio w plikach aspx. Ułatwiło to szybki rozwój podczas pisania strony, ale prawdopodobnie jest to niedopuszczalne, aby utrzymywać ją w ten sposób, ponieważ ściśle łączy ona db z interfejsem użytkownika. Do częściowych klas obiektów EF dodano określoną logikę biznesową.
PYTANIA
Celem refaktoryzacji będzie uczynienie witryny skalowalną, łatwą w utrzymaniu i bezpieczną.
Jaka architektura byłaby do tego najlepsza? Proszę opisać, co powinno znajdować się w każdej warstwie, czy powinienem użyć wzorca DTO / POCO / Active Record itp.
Czy istnieje solidny sposób na automatyczne generowanie DTO / BO, aby wszelkie przyszłe ulepszenia były łatwe do wdrożenia pomimo dodatkowych warstw?
Czy byłoby korzystne przekonwertowanie projektu z WebForms na MVC?
Odpowiedzi:
Wzorzec ASP.NET MVP jest najlepszą architekturą dla długoterminowej aplikacji internetowej ASP.NET. Wchodzi w grę z koncepcją „separacji obaw”, która jest de facto trendem stojącym za wzorcami MV *.
Pytanie: dlaczego z niego korzystać? - szczegółowo omówione w tym poście - ASP.NET MVP
źródło
źródło
Jak wspomniał ElYusubov, wzór MVP może być świetny.
Kluczową koncepcją jest usunięcie większości lub całej logiki z tyłu kodu. Logika nie powinna być powiązana ze stroną. Co jeśli musisz ponownie użyć logiki z jednej strony na drugiej? Będziesz miał ochotę skopiować i wkleić. Jeśli to zrobisz, twój projekt stanie się możliwy do utrzymania.
Tak więc na początek zacznij od refaktoryzacji logiki poza kodem i umieść ją w warstwie biznesowej. Jeśli udało ci się wyciągnąć całą logikę z kodu, możesz zaimplementować niezbędne interfejsy, aby być prawdziwym MVP.
Upewnij się również, że dostęp do danych jest oddzielny od logiki biznesowej. Utwórz warstwę danych i rozpocznij refaktoryzację również na tym końcu. Ponieważ używasz EF4, nie stanowi to większego problemu, ponieważ EF powinien już mieć ten koniec osobny. Powinieneś być w stanie łatwo przenieść wszystkie pliki EF do innego projektu i po prostu dodać odniesienie do projektów, które tego potrzebują. Dodatkową korzyścią może być konieczność odniesienia się do modelu danych w innych projektach.
Aby uniknąć przytłoczenia, przerabiaj stopniowo. Ilekroć dotkniesz fragmentu kodu, zastanów się nad jego refaktoryzacją. Jeśli to zrobisz, z czasem twój projekt może stać się łatwiejszy w utrzymaniu.
Edytować
Zapytałeś o to, czy kod odziedziczy klasę logiki biznesowej. Nie można tego zrobić, ponieważ kod za stroną „is-a”. C # nie pozwala na wielokrotne dziedziczenie, więc klasa za kodem nie może być zarówno stroną, jak i obiektem niestandardowym. Musisz koncepcyjnie oddzielić logikę. Prawdopodobnie jest tak, że kod znajdujący się za nim wykonuje wiele różnych czynności. Klasa powinna zrobić tylko jedną rzecz. Spróbuj pomyśleć o tym, jak możesz koncepcyjnie wycofać istniejącą funkcjonalność. Załóżmy na przykład, że masz stronę rejestracji i zbierasz informacje o użytkowniku. Prawdopodobnie masz przycisk o nazwie register i zdarzenie kliknięcia powiązane z tym przyciskiem. W takim przypadku zapisujesz informacje o użytkowniku i robisz wszystko, czego potrzebujesz. Możesz utworzyć obiekt rejestracji do obsługi całej tej logiki.
To nie tylko czystsze oddzielenie, ale może być również sposobem na samodzielne udokumentowanie kodu. Gdy ktoś przeczyta Twój kod, zobaczy, że wołasz obiekt rejestracji, dzięki czemu dokładnie wiesz, co się dzieje.
Jeśli chcesz ściśle przestrzegać wzorca MVP, zamiast przekazywać parametry do obiektu rejestracji, kod zaimplementuje interfejs. Implementacja interfejsu zasadniczo zamapowałaby wszystkie obiekty widoku (pole tekstowe itp.) Na interfejs. np. publiczny ciąg FirstName {get {return txtFirstName.Text; }}
Gdy to zrobisz, możesz przekazać stronę do obiektu Regisration
Registration.RegisterUser (this);
I ta metoda RegisterUser przyjęłaby interfejs jako parametr
public bool RegisterUser (użytkownik IUser) {user.FirstName ...}
interfejs publiczny IUser {ciąg publiczny FirstName; }
Jeśli ten MVP brzmi myląco, po prostu skup się na refaktoryzacji i wiedz, że celem tego jest maksymalne ponowne użycie kodu. Odtąd się nie powtarzam. To jest zasada SUCHA .
źródło