Architektura NHibernate?

Question

Mam zamiar wdrożyć mój następny projekt (asp.net MVC) przy użyciu nhibernate jako ORM. Ponieważ nie mam doświadczenia z nhibernate, zastanawiam się, w jaki sposób powinienem organizować zależności między różnymi projektami. Widziałem coś takiego jak zalecanego podejścia:

• UI zależy od modelu, repozytoria i NHibernate
• Repozytoria są uzależnione od modelu i NHibernate

 

    ----- UI----------------------------- 
    |    |     | 
    |    |     | 
    Model NHibernate 

Problemem jest to zrobić nie chcę, aby kod interfejsu użytkownika działał bezpośrednio z nhibernate, więc myślę o czymś takim:

• UI zależy od modelu i elewacji
• Fasada zależy od modelu i NHibernate

----- UI -------- | | | | Model

Elewacja, będzie miała repozytorium oraz enkapsulację obiektów nhibernate.

Czy to brzmi rozsądnie? Czy istnieją jakieś wytyczne dotyczące preferowanej architektury?

Niż

Answer 1

ogół jest to, co robię w moich aplikacjach:

• Foo.Rdzeń

  • zawiera obiekty domen, logiki biznesowej itp
  • bez odniesienia do jakichkolwiek infrastrukturalnych związanych z zespołami, takimi jak usługi internetowe, ESBs lub dostępu do danych
  • niektórzy ludzie umieścić również repozytorium interfejsów tutaj, ale to wybór projektu. To pozwala mieć swoje usługi domen tutaj, które współdziałają z repozytoriów, nadal oddzielona od NHibernate

• Foo.Persistence

  • odniesień do NHibernate
  • Repozytorium wdrożeń
  • jednostka pracy HttpModule dla ASP.NET (pomaga kontrolować cykl życia sesji NHibernate w aplikacji internetowej)

• Foo.Web

  • odniesienie zarówno Foo.Core i Foo.Persistence
  • modułu HttpModule odniesienia do sterowania sesją NHibernate

Foo.Web nie oddziałuje bezpośrednio z NHibernate ... zawsze za pośrednictwem repozytoriów. Za pomocą kontenera IoC możesz po prostu zażądać IRepository i nie przejmować się tym, co to jest implementacja.

Answer 2

Catharsis może mieć to, czego szukasz.

Answer 3

Tak. Brzmi nieźle. Nigdy nie korzystałem z NHibernate, ale mając model udostępniony pomiędzy twoim interfejsem użytkownika a fasadą brzmi dobrze. Oczywiście istnieje wiele różnych sposobów osiągnięcia tych samych celów, ale twój wygląda dobrze. :)

Answer 4

Powiedziałeś, że planujesz użyć wzorca MVC. Oznacza to, że twój interfejs nie będzie wchodził w interakcje z warstwą danych (w twoim przypadku, NHibernate). To, co będzie wchodzić w interakcje z warstwą danych, jest warstwą biznesową, a Twój interfejs będzie wchodził w interakcje z warstwą biznesową.

Nie znam środowiska ASP.NET, więc nie mogę doradzić w sprawie gotowej struktury dla tego, ale w Javie, której przede wszystkim używam, twoje EJB izolują twój interfejs użytkownika od warstwa danych, wykonując wszystkie takie połączenia za pośrednictwem EJB.

Pomyśl o wyodrębnieniu kodu dla każdej warstwy. Masz pole dla każdego poziomu, a każde pole może komunikować się tylko z polem pod nim za pośrednictwem określonych kanałów. Tak więc warstwa danych komunikuje się z bazą danych, warstwa biznesowa komunikuje się z warstwą danych, a interfejs użytkownika komunikuje się z warstwą biznesową. Wszystkie te komunikaty są jednokierunkowe (to znaczy, że warstwa danych nie wie o warstwie biznesowej itp.). Oznacza to, że jeśli chcesz zastąpić dowolną warstwę nową implementacją, wpływ na resztę twojego programu może być ograniczony do minimum.

Rzeczywista implementacja, której używasz do NHibernate, nie jest tak naprawdę związana z używaniem MVC, z wyjątkiem faktu, że twój interfejs użytkownika nie będzie wiedział, w jaki sposób dane są przechowywane lub dostępne.