Gdzie powinny znajdować się moje modele? Warstwa sieci Web lub warstwa danych? (MVC + NHibernate)

Konfiguruję aplikację n-warstwową z MVC, Ninject i NHibernate (moje pierwsze użycie tych technologii). Dla jasności, poziomy są warstwą "danych", warstwą "usług" i warstwą "Web" (wszystkie są osobnymi projektami).Gdzie powinny znajdować się moje modele? Warstwa sieci Web lub warstwa danych? (MVC + NHibernate)

W MVC masz modele znajdujące się w folderze "Modele". Konieczne wydaje się tutaj umieszczenie moich modeli w celu stworzenia silnie napisanych widoków i ogólnie trzymania się filozofii MVC.

Jednak w przypadku NHibernate potrzebuję również moich modeli w warstwie "Dane", aby mapowanie mogło mieć miejsce i że NHibernate może tworzyć instancje rzeczywistych obiektów, aby powrócić do warstwy usług.

Powielanie klas pomiędzy projektami nie jest bardzo suche i ich wyodrębnienie do ich własnej biblioteki wydaje się nie działać dobrze z MVC (ani w praktyce, ani w filozofii).

Jakieś myśli? W jaki sposób konstruujesz swoje obiekty O/RM w porównaniu do modeli MVC?

Źródło

2009-02-13 Jeffrey Harrington

jestem ciekawy jak upływ 2 lata potwierdzają to pytanie (poprawione, wzmocnione i inne). Czy MVC3 zmienia równanie? Przygotowuję się do stworzenia hybrydy pomiędzy starszą warstwą danych nH - do - EF, aby wspierać rusztowanie. Jaka jest dziś grupa projektów VS przy mieszaniu NH i EF? - thx – justSteve

Co powiesz teraz !? Prawie 2 lata od zadeklarowania powyższego pytania? –

Przechowuję modele/klasy Entity Framework w warstwie danych i korzystam z folderu Modeli projektu MVC dla modeli prezentacji i segregatorów modeli.

Źródło

2009-02-13 17:56:00

OK. Wygląda więc na to, że konsensus polega na utrzymywaniu modeli prezentacji w warstwie internetowej i moich modelach domen w warstwie danych. A więc co powinien mój poziom usług powrócić do warstwy sieci? Czy powinien wiedzieć o modelach prezentacji? A może powinien zwrócić Modele Domeny? –

Nie, nie sądzę, że usługi powinny wiedzieć o modelach prezentacji. Rzeczywiście, prawdopodobnie nie ma sposobu, aby dana usługa mogła wiedzieć o każdym możliwym modelu prezentacji. Usługa powinna zwrócić obiekty przesyłania, które mogą być typami encji. Warstwa WWW może przekształcić ją w model prezentacji. –

To ma sens. Mimo to to mapowanie modeli domenowych na modele prezentacji nie wydaje się bardzo SUCHE, szczególnie gdy dwa modele będą podobne. –

Wszystkie modele przechowuję w warstwie danych z powodu NHibernate. Spójrz na S#arp Architecture, aby uzyskać świetny sposób na zachowanie czystości prezentacji. Modele nie muszą być fizycznie umieszczone w projekcie WWW, aby Twoje poglądy były silnie typowane.

Źródło

2009-02-13 18:14:03

Model danych to własna rzecz. Model w MVC to coś innego. Jest to model tego, co zamierzasz wyświetlić, co może, ale nie musi być Twoim Modelem Danych. Jesteś Modelem danych może przekraczać warstwy, lub nie.
Weźmy na przykład standardowy formularz rejestracji. Model danych może zawierać nazwę użytkownika, hasło i tablicę klas historii logowania, flagę wskazującą, że jest aktywna i wiele innych rzeczy. Model w MVC może tylko bardzo dbać o nazwę użytkownika i hasło, a także, aby użytkownik dwukrotnie wpisał hasło. Czy twój model danych naprawdę potrzebuje dwóch pól hasła? Nie. Jednak model w MVC ma. Stąd dwa różne stworzenia.

Źródło

2009-02-13 18:27:51

OK. Wygląda więc na to, że konsensus polega na utrzymywaniu modeli prezentacji w warstwie internetowej i moich modelach domen w warstwie danych. A więc jaki poziom usług powinien powrócić na poziom Web? Czy powinien wiedzieć o modelach prezentacji? A może powinien zwrócić Modele Domeny? –

Warstwa usług powinna zwrócić model danych. Lub zadaj sobie pytanie ... co się stanie, jeśli mam inny interfejs uzyskujący dostęp do moich usług? Im mniej warstwa usług wie o front end, tym lepiej będziesz na dłuższą metę. –

W MVC masz modele, które znajdują się w folderze "Modele". Wygląda na to, że konieczne jest umieszczenie moich modeli na , aby utworzyć silnie wpisane widoki i na ogólnie trzymać się filozofii MVC.

Żaden model nie może być cokolwiek, co chcesz. Nadal korzystałbym z modelu prezentacji, gdyby był niezbędny, ale nie mam zastrzeżeń do używania twoich obiektów nhibernate w twoich widokach.

Z NHibernate naprawdę nie potrzebujesz poziomu danych, ponieważ sama sesja jest warstwą danych.

Warstwa usługi wydaje się być prawidłowym pomysłem, ale tylko jeśli planujesz mieć wielu klientów dla tej warstwy.

W przeciwnym razie będę miał tylko 1 projekt i używam przestrzeni nazw do oddzielenia warstw. Buduje się szybciej i jest łatwiejszy do wdrożenia.

Źródło

2009-02-13 18:57:40

"Z NHibernate naprawdę nie potrzebujesz poziomu danych, ponieważ sama sesja jest warstwą danych." Aby zaimplementować wzorzec repozytorium, pobieram warstwę danych. W ten sposób moje usługi są programowane w oparciu o interfejs, a warstwa danych jest łatwo wymienna (tj. Przełączanie O/RM). –

Następnie możesz umieścić swoje jednostki w głównej bibliotece i umieścić swoje repozytoria w swoich usługach. Repozytoria są usługami. –

Masz rację co do zasady DRY. Trzymam moje obiekty LINQ-SQL oddzielone od moich obiektów biznesowych i mam trochę duplikacji i to nie sprawia, że czuję się dobrze, ale wydaje się, że nie ma prostego obejścia tego ..

miałem trudny czas podejmowania tej decyzji, ale patrzyłem bloga Rob Conery przy jednoczesnym budowaniu MVC Storefront iw końcu zdecydowałem się pójść tą drogą (obiekty ORM i obiekty biznesowe)

Źródło

2009-02-21 12:59:14

Gdzie powinny znajdować się moje modele? Warstwa sieci Web lub warstwa danych? (MVC + NHibernate)

Odpowiedz

Powiązane problemy