2013-07-05 30 views
5

Narzędzia: Mvc4, SQL Server, NhibernateMvc4: N architektura tier

uczę architekturę nTier i planują nauczyć się tego z małym przykładzie. Będzie to aplikacja do rejestracji studenta, która będzie miała formularz dla a. imię b. nazwisko c. adres d. Student Id Aplikacja będzie mogła a. Zdobądź ucznia według Id b. Zaproś wszystkich studentów c. Zarejestruj nowych studentów/Zapisz ucznia d. Edytuj ucznia e. Usuwanie studentowi

planuję mieć następujące kondygnacje

Warstwa prezentacji (projekt oddzielna aplikacja MVC 4)

--- html do formularza student idzie tutaj. Mogę używać jquery itp. Tutaj --- mój kontroler zadzwoni do usługi

Warstwa usługi (samodzielny projekt: projekt biblioteki klas, w tym przypadku tylko Internet będzie moim klientem.) Nauczę się korzystać z webAPI lub wcf dla to później w innym projekcie)

--- StudentService tutaj

--- IstudentService tutaj

warstwa działalności: (indywidualne projektu: projekt biblioteki klas) ??

Warstwa danych: (oddzielny projekt: projekt biblioteki klas) ??

Database (baza danych serwera SQL)

teraz mam mylić i moje pytania są następujące: (?, Która warstwa)

  1. gdzie będę tworzyć mój model studencki

  2. Co będzie Piszę w mojej warstwie biznesowej dla tego przykładowego studenta, który mam.

  3. Co będzie w mojej warstwie danych? Jakie metody będę pisać? Czy są to metody, które bezpośrednio komunikują się z bazą danych ?

    Niektóre przykłady będą świetne. Poszukam dobrego kontenera IOC.

Oto przykładowy kod poniżej:

public interface IStudentService 

    { 
     IEnumerable<Student> GetStudents(); 

     Student GetStudentById(int id); 

     void CreateStudent(Student student); 

     void UpdateStudent(Student student); 

     void DeleteStudent(int id); 

     void SaveStudent(); 
    } 

public class StudentService : IStudentService 
    { 
     private DataContext _datacontext; 
     public StudentService() 
     { 
      _datacontext = new DataContext(); 
     } 

     public IEnumerable<Student> GetStudents() 
     { 
      var students = _datacontext.Students; 
      return students; 
     } 

     public Student GetStudentById(int id) 
     { 
      return _datacontext.Students.Find(id); 
     } 

     public void CreateStudent(Student student) 
     { 
      _datacontext.Students.Add(student); 
      _datacontext.SaveChanges(); 
     } 

     public void UpdateStudent(Student student) 
     { 
      _datacontext.Entry(student).State = EntityState.Modified; 
      //_datacontext.Entry(student).State = EntityState.Modified; 
      _datacontext.SaveChanges(); 
     } 

     public void DeleteStudent(int id) 
     { 
      var student = _datacontext.Students.Find(id); 
      _datacontext.Entry(student).State = EntityState.Deleted; 
      _datacontext.SaveChanges(); 
     } 

     public void SaveStudent() 
     { 
      _datacontext.SaveChanges(); 
     } 
    } 

Odpowiedz

1

Trzeba spojrzeć na Onion Architecture. Jest nieco przestarzały pod względem wersji MVC, ale warstwy są wielowarstwowe.

Jeśli chodzi o pojemnik IoC, polecam przeglądać na Autofac - łatwy w użyciu z wieloma funkcjami, takimi jak rejestracja według konwencji i wielu dzierżawców.

Co do pytania:

Co ja zwykle jest formą przedstawienia, kontroler dostanie StudentViewModel złożone, to chciałbym przekonwertować go na Student przedmiotu i przekazać IStudentRepository który jest wstrzykiwany do kontrolera. I IStudentRepositry zapisze go w DBContext. Interfejs repozytorium byłby osadzony w warstwie Domain, ale implementacja repozytorium byłaby w warstwie danych. I kontener DI będzie pasował jeden do drugiego.

Podejście polega na tym, aby wszystkie interfejsy w warstwie domeny i implementacjach były umieszczone w dowolnym miejscu. I warstwa domeny nie powinna być zależna od żadnej innej warstwy (czytaj Projekt domeny nie odwoływałby się do danych i projektów internetowych). Ale internet będzie zależał od warstw danych i domeny. Do skonfigurowania kontenera IoC potrzebna jest tylko warstwa danych w warstwie internetowej, ponieważ warstwa sieciowa jest zbiorczym katalogiem głównym, a IoC powinien być tam skonfigurowany. Ale nigdy nie powinieneś używać obiektów Data bezpośrednio w żadnej z operacji, powinieneś wstrzykiwać interfejsy do repozytoriów lub usług.

Wiele się mówiło o architekturze warstwowej, więc najpierw zacznij od architektury cebuli, wtedy będziesz miał lepsze wyobrażenie o tym, czego potrzebujesz.

+0

Nie jestem pewien, czy Architektura Cebuli to dobra rzecz dla kogoś, kogo się tylko uczy, ponieważ różne artykuły zwykle zawierają dużo wiedzy. Myślę, że OA to dobry "drugi krok" po wykonaniu tradycyjnego trójwarstwowego warstwowania. –

+0

Kontener IoC został wymieniony, więc założyłem pewien poziom wiedzy. Pamiętam, że sam się tego nauczyłem. Zrobiłem porządny bałagan "klasycznej" 3-warstwowej aplikacji. Ale kiedy próbowałem OA, sprawy weszły we właściwe miejsce i wszystko działało ładnie. – trailmax

+1

Tak, ale fakt, że nauczyłeś się wiele z "właściwego bałaganu", który sprawił, że OA ma dla ciebie sens.Uważam, że OA to dużo "rób to, ponieważ tak powiedziałem", jeśli nie nauczyłeś się problemów, które rozwiązuje OA. –

2
  1. Tworzysz swój model w warstwie danych. Będziesz także tworzyć modele w warstwie prezentacji (dla swoich modeli widoków). Zwykle wykonujesz jakieś odwzorowanie między modelem danych a modelem prezentacji w kontrolerze.

  2. Proste aplikacje często nie potrzebują warstwy biznesowej. Zwłaszcza jeśli Twoja aplikacja zapisuje dane z formularzy w tabelach. Jednak w takiej aplikacji możesz np. "Nie możesz zarejestrować się w tej klasie, chyba że już ukończyłeś tę klasę" lub możesz mieć "Już zarejestrowałeś się na więcej lekcji niż ci wolno" lub nie. Są to reguły biznesowe, które muszą być egzekwowane gdzieś, a to zwykle w warstwie biznesowej.

  3. Twoja warstwa danych będzie prawdopodobnie Twoim modelem Entity Framework. To tylko kod do załadowania i zapisania modelu do bazy danych.

Istnieje wiele kontenerów IoC .. Lubię Ninject, ale inni ludzie lubią inne. Zwykle jest to kwestia osobistych preferencji.

Powyższe jest, jak można to zrobić w prostej aplikacji. W bardziej złożonych aplikacjach możesz mieć również model w warstwie biznesowej. Wszystko zależy od złożoności aplikacji i od tego, czy chcesz reprezentować dane na poziomie biznesowym inaczej niż na poziomie modelu danych.

Na przykład możesz mieć listę obiektów biznesowych w warstwie biznesowej, ale te obiekty są reprezentowane w warstwie danych inaczej, ze względu na wydajność. Ale na tym wszystkim nie należy się martwić. Rozumiem, że w miarę, jak twoje aplikacje stają się bardziej złożone, możesz mieć potrzebę robienia różnych rzeczy.