Най-добрият дизайн за домейн услуга

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

Работният процес на приложението, което ще използва тази услуга:

  1. Потребителят избира някои условия (като дата и други данни)
  2. Той получава списък с "предложения" на субектите. Той може да избере всички от тях или само някои.
  3. Субектите са създадени

Какъв би бил най-добрият дизайн за услугата за домейн? Имам две предвид:

Решение 1

interface IMyDomainService
{
    IEnumerable<EntityProposition> GetEntitiesPropositions(Conditions conditions);
    void CreateEntities(Conditions conditions);
}

В този случай вероятно ще имам някакъв частен метод в услугата, който ще се използва и от двамата. Класът EntityProposition е основно 1:1 от това, което ще бъде показано в изгледа. В този клас има някои данни, които не са част от самия обект.

Решение 2

interface IMyDomainService
{
    IEnumerable<EntitiyData> GetDataForEntities(Conditions conditions);
    void CreateEntities(IEnumerable<EntityData> entities);
}

Какъв би бил частният метод в Решение 1, сега е изложено в интерфейса. Класът EnityData съдържа всички данни за обекта, които са подходящи за създаване на самия обект и показване на всички данни за преглед.

За да добавите малко контекст: Тази услуга вече се използва директно от ASP.NET MVC контролера. Струва ми се, че ако отида с решение №2, ще трябва да създам някаква допълнителна услуга за приложения, така че тя ще обвие логиката на получаване на данните и създаване на обекти.

РЕДАКТИРАНЕ 1

Ще задам въпроса от друга гледна точка: Трябва ли моят контролер да изглежда така:

public ActionResult GetPropositions(Condtidions condtitions)
{
    var entitiyData= service.GetEntityData(conditions);
    return Json(entitiyData.ToViewModel());
}

public void CreateEntities(Conditions conditions)
{
    var entitiyData= service.GetEntityData(conditions);
    service.CreateEntities(entitiyData);
}

or:

public ActionResult GetPropositions(Condtidions condtitions)
{
    var propositions = service.GetPropositons(conditions);
    return Json(propositions.ToViewModel());
}

public void CreateEntities(Conditions conditions)
{
    service.CreateEntities(conditions);
}

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

Редактиране 2

Само като продължение: Първо избрах Решение №2, но по-късно изискванията ми се промениха и трябваше да се върна към Решение №1. Причината е, че след генериране на предложения потребителят може да избере няколко от тях, но със същия обхват (условия).


person Botis    schedule 18.06.2013    source източник
comment
Наистина се надявам, че методът ToViewModel е метод за разширение. Защото не принадлежи към домейна. Що се отнася до вашата редакция, GetPropositons звучи повече като езика на домейна.   -  person jgauffin    schedule 19.06.2013
comment
Изобщо няма ToViewModel, това е само в примера, за да покаже, че резултатът е картографиран към модела на изглед, след като бъде извлечен. Благодаря за вашата помощ!   -  person Botis    schedule 19.06.2013


Отговори (1)


Кой е най-честият случай? Създаване на много обекти или създаване на един?

Също така не бих използвал Entites в имената на методите, доста очевидно е, че услугата работи с обекти.

За мен името звучи така, сякаш просто обвивате хранилище с услугите. Това е голямо не-не. Услугите в DDD са разширение на обекти на домейн за капсулиране на логиката, където трябва да работите с два или повече обекта в един и същ бизнес случай.

Ако просто трябва да извлечете обект, да го промените и запазите, трябва да използвате директно хранилището (няма нужда да абстрахирате абстракция).

interface IMyDomainRepository
{
    IEnumerable<EntitiyData> GetData(Conditions conditions);
    void Create(IEnumerable<EntityData> entities);
}
person jgauffin    schedule 18.06.2013
comment
Що се отнася до въпрос №1 - бих казал, че най-често срещаното би било да се създадат обекти от всички предложения. Обектът е просто заместител - имам по-добри имена в моя код :) Това не е просто get-›edit-›save. Да кажем, че имам някакво свойство bool в данните на обекта и докато създавам обекта, имам логика като if (това свойство && somethingelse && x›8) entity.children.add(something) - person Botis; 18.06.2013
comment
тази логика принадлежи на самия обект, а не на услуга. - person jgauffin; 18.06.2013
comment
+1 Напълно съм съгласен с вашия отговор. Въпреки това изглежда, че EntityProposition е друг обект в домейна/ограничения контекст - не просто набор от параметри, които се подават в хранилището. Звучи сякаш това, което всъщност искаме тук, е фабрика. - person MattDavey; 18.06.2013