Architektura aplikacji - Web aplikacja

0

Dzień dobry,
Chciałbym się doradzić bardziej doświadczonych programistów w sprawie architektury mojego projektu.
Projektuje aplikacje webową i chciałbym to zrobić w sposób który umożliwi późniejszy łatwiejszy rozwój czy też podpięcie innych projektów do modelu danych.

A więc tak założyłem dwa projekty
-WAS.Repository
-WAS.WebApplication

W Repository znajduje się model danych wygenerowany za pomocą EF ( podejście database first) oraz klasa WASDao w której znajdują się metody dostępowe.

public class WASDao

protected List<Document> getCurrentDocumentList(string arg){
   using(var db = new WASContex()){
    .......
   }
}

....itd...

W WebApplication klasa CommonServices dziedziczy po klasie DAO a następnie udostępnia Controllerowi poszczególne metody. Klasa ta ponadto zajmuje się mapowanie klas modelu na ViewModele.

public class CommonServices : WASDao

[Authorize(Roles="Admin")]
public List<DocumentViewModel> GetCurrentDocumentList(string arg){
    var model = getCurrentDocumentList(arg); 
    return mapper.Map<DocumentViewModel>(model); 
}

....itd...

I tutaj pojawia się moje pytanie czy moje podejście jest prawidłowe ? Czy metody z klasy DAO powinny zwracać obiekty z modelu danych czy może jednak powinienem najpierw zrzutować to do klas DTO ?
Pozdrawiam

2

To może zacznijmy od podstaw podstaw:

  • lekcja pochodząca z książki GoF : preferuj kompozycje i agregacje ponad dziedziczenie
  • lekcja pochodząca z CleanCode : znaczące nazwy (to nie są znaczące nazwy : WASDao, CommonServices)
  • lekcja pochodząca z Agile:PPP : SRP -> CommonServices wskazuje że to nie będzie mialo pojedyńczej odpowiedzialności ;)

póki co tworzysz coś co nie będzie łatwe w późniejszym rozwijaniu i utrzymaniu, już na poziomie kodu, a nie architektury

1

czy zastosowanie dziedziczenia w tym przypadku jest błędem ? jakie będzie mieć zalety zastosowanie kompozycji ? 2) masz rację nazewnictwo może nie zbyt trafne na początku. Moją ideą docelową jest zaprojektowanie CommonServices+UserServices+..... Czyli dla każdej roli osobna klasa services. W klasie CommonServices chciałbym zawrzeć metody które są wykorzystywane przez wszystkie role. Czy to złe podejście ?

Dużo tutaj do gadania ja polecam na początek "The Object-Oriented Thought Process". Większość ludzi przerasta na samym początku Clean Code czy Agility.

Powinieneś zacząć myśleć o całości jako pakietach nie klasach. Koncepcja w której jeden pakiet dziedziczy po drugim jest bez sensu ponieważ jest to zbyt mocne związanie.
Do tego używa się dependency Inversion (przypominam że wystawienie interfejsu tam gdzie się da to nie jest prawdziwe DI).

Autoryzacją powinien się zajmować kontroler lub widok.

0

A liczyłem na jakieś konkretne wpisy w takim temacie :(

1 użytkowników online, w tym zalogowanych: 0, gości: 1