porady dotyczące architektury aplikacji asp.net mvc

Question

Używam ASP.net MVC od około dwóch lat i nadal uczę się najlepszego sposobu na strukturę aplikacji.

Chciałem rzucić te pomysły, które zebrałem i zobaczyć, czy są one "akceptowalne" sposoby w społeczności do projektowania aplikacji MVC.

Tu jest mój podstawowy układ:

• DataAccess Projekt - Zawiera wszystkie repozytorium klas, LINQ-SQL kontekstów danych, filtry i niestandardowych obiektów biznesowych dla repozytorium non-MS SQL db (który LINQ-SQL nie tworzy). Repozytoria mają zwykle tylko podstawowy CRUD dla obiektu, którym zarządzają.

• Projekt usługi - Zawiera klasy usług, które wykonują logikę biznesową. Biorą rozkazy od kontrolerów i informują repozytoria, co mają robić.

• Projekt UI - Zawiera modele widoku i niektóre opakowania wokół obiektów takich jak ConfigurationManager (do testowania jednostkowego).

• Główny projekt MVC - Zawiera kontrolery i widoki, wraz z javascript i css.

Czy wydaje się to dobrym sposobem na strukturę aplikacji ASP.NET MVC 2? Wszelkie inne pomysły lub sugestie?

Czy modele widoku używane są do wszystkich wyników dla widoków i danych wejściowych z widoków?

Przechodzę ścieżką tworzenia modeli widoku dla każdego obiektu biznesowego, który musi wyświetlać dane w widoku i uczynić je podstawowymi klasami z grupą właściwości, które są wszystkimi ciągami. To sprawia, że ​​radzenie sobie z poglądami jest dość łatwe. Warstwa usługi musi następnie zarządzać właściwościami odwzorowania z modelu widoku do obiektu biznesowego. Jest to źródłem niektórych z moich nieporozumień, ponieważ większość przykładów, które widziałem na MVC/MVC2, nie używa modelu widoku, chyba że potrzebujesz czegoś takiego jak pole kombi.

Jeśli użyjesz nowej metody sprawdzania poprawności modelu MVC 2, czy sprawdziłbyś poprawność obiektu viewmodel i nie musiałbyś się martwić o umieszczanie atrybutów sprawdzania poprawności na obiektach biznesowych?

W jaki sposób jednostka testuje ten typ sprawdzania poprawności, czy też nie powinienem testować jednostki, czy zwracane są komunikaty o walidacji?

Dzięki!

Answer 1

Interesujące.

Jedną rzeczą, którą robię inaczej jest to, że odłączyłem mój projekt DataAccess od mojego projektu Domain. Projekt domeny nadal zawiera wszystkie interfejsy dla moich repozytoriów, ale mój projekt DataAccess zawiera wszystkie ich konkretne implementacje.

Nie chcesz, aby elementy takie jak DataContext wyciekały do ​​projektu Twojej domeny. Po onion architecture twoja domena nie powinna mieć żadnych zależności od zewnętrznej infrastruktury ... Uważałbym, że DataAccess to ma, ponieważ jest bezpośrednio powiązana z bazą danych.

Dzielenie ich oznacza, że ​​moja domena nie ma zależności od ORM lub bazy danych, więc mogę je łatwo wymienić, jeśli zajdzie taka potrzeba.

Cheers,
Charles

Ps. Jak wygląda twoja zależność od projektu? Zastanawiam się, gdzie umieścić moje ViewModels. Może oddzielny projekt interfejsu użytkownika jest dobrym pomysłem, ale nie jestem do końca pewien, jak by to działało. W jaki sposób przepływają przez różne poziomy projektu w aplikacji?