Модел на услуга и хранилище и разделяне на притесненията

Използвам шаблон за проектиране на слой услуга/хранилище върху Entity Framework. Всичко беше наред, докато не поисках заявка да върне обединяване на данни за две отделни единици.

Примерът е, че имам двата обекта Document и ShoppingBasketItem. Така че сега имам две услуги DocumentService и ShoppingBasketService. Първоначално просто изброих документите въз основа на потребителско търсене. Но по-късно исках да подчертая документите, които вече са в пазарската кошница на потребителите. Така че службата за документи сега трябва да знае за концепцията за пазарски кошници.

Наистина исках услугата за документи да няма нищо общо с кошниците за пазаруване, ясно разделение на проблемите.

Та въпросът ми е, това добър подход ли е? Или евентуално да създам нова услуга DocumentBasketService, която обработва заявки относно информация за документи и кошници за пазаруване?


person Leigh Ciechanowski    schedule 03.01.2013    source източник


Отговори (2)


Та въпросът ми е, това добър подход ли е?

Зависи.

Имам някои резерви в подхода за дефиниране на услугите по този начин. Бихте искали да постигнете SoC, което е умно нещо, но мисля, че трябва да работим върху определението за загриженост. Загрижеността наистина ли е обект на домейн в този случай? Съдейки по проблемите, с които се сблъсквате, не изглежда така.

Виждал съм това да се прилага много пъти отново: в крайна сметка може да изглежда логично да се дефинира DocumentService, работеща с DocumentRepository. Според моя опит те в крайна сметка препращат някои/повечето от обажданията към хранилището директно и имат огромен договор за услуга, защото в крайна сметка всичко, което е свързано с Документи, ще завърши в DocumentService.

Ако правите ориентация към услугата, решението, което обикновено приемам, е да накарам моите услуги да говорят „бизнес“, а не домейн, като ги накарам да прилагат бизнес казуси, а не да ги прехвърлят към опаковане на хранилище. След това можете да постигнете SoC във вашите услуги и вашите притеснения са бизнес притеснения: дефиницията на тези притеснения обаче зависи изцяло от вашите бизнес случаи, което означава, че не мога да ви помогна там. OTOH, ако наистина имате нужда от домейн услуги, този съвет е напълно безполезен; както казах, зависи от вашите нужди.

Така че точката, която е универсално валидна, е: преразгледайте какви проблеми се опитвате да разделите и какво искате да постигнете с това.

person Filippo Pensalfini    schedule 03.01.2013
comment
+1. Добър отговор. Но Аз съм архитект ме накара да въздъхна дълбоко, почти да спра да чета и да гласувам -1 (накара ме да си помисля, че ето още един кандидат-архитект, който иска да се похвали). Няма нужда от такива коментари. Вашият отговор е добре обмислен и мотивиран. Продължавай така. - person jgauffin; 04.01.2013
comment
@jgauffin съжалявам, че беше замислено като шега с факта, че зависи от това е стандартен отговор на архитект на подобни въпроси, но очевидно не е излязъл правилно, така че ще го премахна :) все пак благодаря за милите думи. - person Filippo Pensalfini; 04.01.2013
comment
може би само аз бях уморен (или тъп) ;) - person jgauffin; 04.01.2013

Хм, може би съм измислил отговор, който запазва ясното разделение на притесненията.

Добавих нов метод към услугата за документи, който приема като параметър списък с идентификатори на документи, тези идентификатори са документите, които вече съществуват в потребителската кошница за пазаруване. Тогава услугата може просто да маркира документите, напр. задайте свойство на документа, за да посочите, че той вече е в пазарската кошница на потребителя.

По този начин услугата за документи не търси пазарски кошници и наистина не знае нищо за тях.

И така, за да обобщя моето действие на контролера извиква услугата за пазарска кошница и получава списък с идентификатори, които вече са в потребителската кошница за пазаруване. След това извиква метода за получаване на документи на услугата за документи, предавайки списъка с идентификатори.

person Leigh Ciechanowski    schedule 03.01.2013