2009-08-27 10 views
5

Budowałem nową aplikację przy użyciu mojego obecnego rozumienia projektowania opartego na domenie. Do tej pory mam pęczku klas reprezentujących podmioty w mojej domenie i repozytorium do pobrania z/persist do bazy danych.Domain Driven Design: jak odzyskać listy złożonych danych

Problem polega na tym, że w interfejsie użytkownika muszę wyświetlić kilka list, w których elementy na liście nie są mapowane bezpośrednio do żadnych elementów w mojej domenie. Niektóre listy można zbudować, wykonując dość głęboki ładunek pewnych elementów, ale inne dane są zasadniczo syntetyzowane w czasie pobierania i nie są częścią żadnej jednostki. Pozwólcie, że przedstawię przykład, który, mam nadzieję, wyjaśni sprawę dokładniej.

W mojej domenie mam oceny (zestaw pytań do odpowiedzi) i odpowiedzi (odpowiedzi, które każdy użytkownik przekazał do oceny) do tych ocen. Mam też akcje. Każde działanie reprezentuje akcję, która została podjęta z odpowiedzią (przesłanie, zatwierdzenie, odrzucenie itp.). Mam też użytkowników.

Jedna z list danych, które muszę wyświetlić, zawiera odpowiedzi i oceny (na które nie odpowiedziano), a następnie każda linia zawiera informacje o użytkowniku, który aktualnie pracuje z odpowiedzią (jest to określone na stronie czas wyszukiwania, patrząc na działania, które zostały podjęte w odpowiedzi). Każdy element zamówienia będzie również zawierał zero lub więcej elementów podrzędnych, które są działaniami, które zostały podjęte w odpowiedzi na razie.

Problem polega na tym, że obecnie nie mam możliwości reprezentowania całego zestawu danych z moimi jednostkami domeny. Moją pierwszą reakcją byłoby po prostu pobranie danych z bazy danych i ominięcie moich jednostek domeny. Ale widzę dużą wartość w pracy z obiektami domeny i utrzymywaniem relacji między różnymi istotami upieczonymi do samych obiektów. Tak więc moim następnym pomysłem byłoby zmodyfikowanie moich jednostek domenowych w celu obsługi tych list, ale obawiam się, że dodam do moich podmiotów dziwne właściwości tylko po to, by obsługiwać te scenariusze aukcji i że może to być bolesne działanie, zasadniczo robiąc duże ilości obiektów, gdy potrzebuję tych danych tylko w kilku miejscach w moich aplikacjach.

Odpowiedz

2

Proponuję, aby nie wyświetlać tego jako czegoś, co musisz włożyć w swoje jednostki, ale raczej zapewnić usługę usługi (w żargonie projektowania opartego na domenie), której zadaniem jest zbieranie tych danych na żądanie i przedstawianie go jako widok. To uwalnia cię od konieczności przerabiania twoich bytów w przylegający sposób.

Problem polega na tym, że od teraz nie mam możliwości reprezentowania całego zestawu danych za pomocą moich encji domeny.

Niezręczne tarcie w projekcie, które tu odczuwacie, jest dobre. Jest to wskazówka, że ​​rzeczy nie pasują do siebie.

+0

Ok, teraz czytam o usługach. Kiedy powiesz, że usługa przedstawi dane jako widok, jaki jest widok? Czy jest to klasa zdefiniowana właśnie w tym celu? Czy składa się z podmiotów domeny? –

+1

Używam widoku w sensie MVC - to jest coś, czego zadaniem jest pokazywanie ci rzeczy. Rzeczywiste istotne dane zostaną zebrane przez usługę, która następnie zostanie przekazana i poproszona o wyświetlenie (w twoim przypadku jest to "lista danych", o której wspomniałeś).Usługa może również zdecydować o zawijaniu informacji w oddzielnych klasach (szczególnie jeśli wiele widoków używa tych samych danych) przed przekazaniem ich do widoków, ale w żadnym wypadku nie jest to wymagane. –

2

Wygląda na to, że (poprzez pojawienie się tego problemu) zidentyfikował problem z modelem Twojej domeny. Abstrakcja, którą chcesz wyświetlić w każdym z tych list, najwyraźniej nie jest dobrze reprezentowana w twoim modelu domeny ani w twoim "wszechobecnym języku". Zdecyduj, co to jest, nadaj mu nazwę i dodaj kod do repozytorium, aby wygenerować listy tych obiektów, niezależnie od tego, czy są one obiektami, czy obiektami wartości ...

+1

Rzeczywiście - być może nie rozumiem problemu, ale moje początkowe wrażenie jest takie, że podmioty domeny potrzebują tylko dodatkowych właściwości: np. Jednostki Response powinny mieć właściwość Actions (lub ActionHistory), aby reprezentować "działania, które zostały podjęte w odpowiedzi jak dotąd." –

+0

Wygląda na to, że rozumiesz problem, który mam. Zastanawiam się nad dodaniem tych dodatkowych właściwości, ale szczerze mówiąc część mojej troski o to, że wiąże się to prawdopodobnie z ładowaniem większej ilości danych, niż naprawdę potrzebuję w pewnych momentach. Działania są dość proste i nie stanowiłyby problemu, ale moje jednostki użytkownika są dość skomplikowane i wydaje się, że dużo pracy wymaga załadowanie całego użytkownika, gdy wszystko, czego naprawdę potrzebuję, to identyfikator i nazwa użytkownika. Ale częściowe ładowanie bytu wydaje mi się naprawdę hackowskie. –

+1

Jeśli chodzi o wydajność/optymalizację, odpowiedź Johna Feminella (aby stworzyć metodę obsługi w celu jej obsługi) zdecydowanie byłaby odpowiednia. Powiedziawszy to, wiele narzędzi OR/M pozwoli ci leniwko załadować te właściwości (co jest dyskusyjne, oczywiście, jeśli nie używasz jednego z nich lub nie toczysz własnej warstwy/repozytorium dostępu do danych). –

Powiązane problemy