Таблицы поиска на основе доменного дизайна в качестве совокупного корня - PullRequest
2 голосов
/ 25 марта 2012

У нас есть веб-приложение, в котором вы можете получить доступ к двум услугам / функциям («Купить» и «Аренда»).На первом этапе вы должны выбрать ProductCategory из DropDownList.Не каждую товарную категорию можно купить или арендовать.У нас есть 5 категорий продуктов:

  • A: Покупка / Аренда
  • B: Покупка / Аренда
  • C: Покупка / Аренда
  • D:Только Покупка
  • E: Только Аренда

Как я могу спроектировать это с помощью домена?По моему мнению, свойство покупки / аренды не является свойством категории продукта, но принадлежит самой услуге:

public class Service
{
     public string Name; // Buy or Rent
     public List<ProductType> AllowedTypes; 
}

Изменить второй пример:

Обе службы имеют несколько общих статусов (например, созданыили завершено), но также особый статус (например, «Buy-Status-1»).Это хорошая идея использовать для обоих сервисов один и тот же класс статуса?Или лучше специализированный класс на услугу BuyStatus / RentStatus.

1 Ответ

4 голосов
/ 25 марта 2012

Я думаю, это зависит от того, является ли отношение "купить / арендовать" против "только покупка / только аренда" статическим или динамическим .

Если отношениестатичен (раз и навсегда), может быть проще иметь эту информацию непосредственно на ProductCategory.Чем меньше классов, тем лучше.

С другой стороны, если отношение является динамическим, то назначение другого объекта, ответственного за поддержание таких знаний, может упростить управление динамическим состоянием (например, продукт может быть сдан в аренду).только на некоторое время, а затем «купить / арендовать» еще какое-то время и т. д.).

Это следует правилу oop, которое гласит, что свойства - это просто значения, и когда свойства становятся более сложными (например, они изменяются во времени, и вы должны следить за всеми изменениями), тогда вы перемещаете их в отдельные классы.

...