Najlepsza architektura dla aplikacji ASP.NET WebForms

10

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ą.

  1. 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.

  2. Czy istnieje solidny sposób na automatyczne generowanie DTO / BO, aby wszelkie przyszłe ulepszenia były łatwe do wdrożenia pomimo dodatkowych warstw?

  3. Czy byłoby korzystne przekonwertowanie projektu z WebForms na MVC?

stos ludzi
źródło
1
Zwolnij wcześniej, zwolnij często Sugeruję, aby twój klient nie przejmował się tak bardzo, jeśli nie masz konkretnych problemów biznesowych do przedstawienia (np. Jest to niepewne). Być może powinieneś trochę posprzątać (upewnij się, że jest przenośny) i zwolnić, a następnie podjąć to jako długoterminową inicjatywę - przekształcić się w MVC lub podobny.
gahooa
2
Nie zmieniaj działającej technologii projektu na nową technologię xyz tylko dlatego, że istnieje, szczególnie jeśli Twój projekt działa poprawnie. Jeśli działa, nie rób tego. Biznes nie dba o kod. Najważniejsza jest funkcjonalność na koniec dnia.
NoChance
ok, to prawda, jednak moim zmartwieniem jest to, że po wydaniu będzie trudniej zrefaktoryzować ze względu na ryzyko złamania go, gdy stawki są znacznie wyższe. Utknęlibyśmy więc w kodzie, który nie jest tak łatwy w utrzymaniu i trudniejszy do debugowania itp. Kusiło mnie, aby nauczyć się / przekonwertować na MVP, ale wyglądało to na zbyt wiele pracy. Do tej pory właśnie przekonwertowałem go na warstwy DAL, Domain, UI, które wydają się bardziej zorganizowane, ale wciąż pozwalają na nieuniknione RAD, które będą potrzebne, gdy projekt będzie młody. Pewnego dnia, jeśli to konieczne, mogę rozwinąć się do MVP lub MVC, jak sądzę - po tym, jak mam wystarczająco dużo czasu, aby dowiedzieć się, jak to wszystko działa.
stack man
Nadal czuje się bałagan: 1) Obiekty EF w interfejsie użytkownika (kod za plikami w warstwie interfejsu)
stos człowiek
(2) Logika biznesowa w rozszerzonych obiektach EF, które musiały przejść w warstwie DAL (nie zdawała sobie sprawy, że klasy częściowe muszą znajdować się w tym samym zestawie) (3) Logika biznesowa w plikach aspx.cs w warstwie interfejsu użytkownika. Wydaje się jednak, że w przypadku architektury często występują kompromisy, ale z pewnością jest to krok naprzód. Wydaje mi się, że jest to do przyjęcia w pierwszym wydaniu i z czasem możemy ponownie ocenić nasze podejście. Dziękuję wszystkim za pomoc. Dobrze jest uzyskać trochę kierunku, ponieważ ten obszar jest tak subiektywny.
stos ludzi

Odpowiedzi:

5

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

Jusubow
źródło
Problem polega na tym, że refaktoryzacja projektu do MVC wymagałaby dużo pracy ... jeśli zatrzymam go jako aplikację WebForms z warstwą domeny (najpierw kod, POCO), warstwą dostępu do danych (tylko kontekst db) i interfejsem użytkownika, czy uważasz to za akceptowalny projekt do produkcji? W późniejszym terminie moglibyśmy rozważyć konwersję do MVC.
stos ludzi
Cóż, jest to wzorzec MVP (model-widok-prezenter), a NIE MVC (model-widok-kontroler).
Yusubov
1
o przepraszam - źle odczytałem. Dziękuję - przeczytam o projekcie MVP.
stack man
nie ma problemu, mam nadzieję, że znajdziesz to, czego szukasz :)
Yusubov
Wydaje się, że przejście na MVP byłoby również istotną zmianą. Klient chce wkrótce wydać, więc czy uważasz, że wyżej wspomniana architektura DAL / DA / UI (choć nie tak idealna jak MVP) byłaby do przyjęcia dla tego typu aplikacji? Następnie po wydaniu moglibyśmy przejść na MVP w wersji 2.
stack man
1
  1. Użyj wzorca MVP dla osobnego i logicznego i interfejsu użytkownika, więc w przyszłości możesz przejść do innej technologii interfejsu, ponownie wykorzystując istniejącą logikę
  2. Użyj wzorca repozytorium między BL i DAL, aby przejść do dowolnego RDBS wykorzystującego logikę biznesową
  3. wprowadzają osobne warstwy (Dll) dla BO i DAL, co minimalizuje potrzeby konserwacji.
Arunachalam
źródło
Nie jestem pewien, dlaczego ktoś głosował na to pytanie. Szczerze mówiąc, jest to najbardziej zwięzła odpowiedź. +1
Greg Burghardt
0

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 .

koder
źródło
Dziękuję za pomocne wskazówki. Tak, z pewnością byłem trochę przytłoczony tym. Wydaje mi się, że MVC byłby najlepszym wzorem do użycia, ale MVP byłby łatwiejszy do osiągnięcia i byłby kolejnym najlepszym wzorem. Zawsze używałem kodu za plikami, więc zawsze zastanawiałem się, jak można oddzielić logikę biznesową od prezentacji ... więc powinienem być w stanie przenieść moje pliki .aspx.cs do warstwy domeny i mieć dziedziczoną instrukcję w aspx ? Z pewnością skończenie z 3 warstwami sprawiłoby, że czułbym się komfortowo z wydaniem pierwszej wersji - wtedy mogę ją ulepszyć.
stack man
Odpowiem na twój komentarz w mojej odpowiedzi. Zachęcam do głosowania na moją odpowiedź, jeśli okaże się przydatna
koder