Какие типы кода подходят для уровня обслуживания? - PullRequest
Новая
       19

Какие типы кода подходят для уровня обслуживания?

4 голосов
/ 23 июня 2011

Предположим, у вас есть сущности, сервисный уровень и репозитории (с ORM, как NHibernate).Интерфейсы взаимодействуют с уровнем обслуживания.

Какие типы кодов подходят для уровня обслуживания?

Координация хранилища?

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

Бизнес-логика, которая включает в себя хранилища?

Если вышеприведенное верно, следует ли что-то вроде проверки, является ли имя пользователя отличным, перейти на уровень обслуживания (т.е. вызвать GetUsersByUsername и проверить результаты)?Прежде чем предположить, что БД должна обрабатывать разные данные, как насчет проверки того, что пароль не использовался в течение 90 дней?

Бизнес-логика, включающая несколько объектов?

Я не уверен насчёт этого, но скажу, что у вас есть необходимость применить операцию к совокупности сущностей, которые могут или не могут быть связаны и на самом деле не применимы к одной сущности.Должны ли сущности быть в состоянии работать с этими коллекциями, или они принадлежат к уровню обслуживания?

Отображение?

Используете ли выDTO или отправьте свои сущности на / с вашего уровня обслуживания, вы, скорее всего, в конечном итоге сопоставления (желательно с AutoMapper).Это относится к сервисному уровню?

Я ищу подтверждение (или отклонение) идей, перечисленных выше, а также любые другие мысли об ответственности сервисного уровня при работе с сущностями /хранилища.

1 Ответ

2 голосов
/ 25 июня 2011

Координация хранилища?

Совокупные корни должны рисовать транзакционные границы. Поэтому - несколько репозиториев должны быть задействованы редко. Если они есть - это обычно происходит, когда Вы создаете новый агрегатный корень (в отличие от изменения его состояния).

Бизнес-логика, которая включает хранилища?

Да, проверка, является ли имя пользователя отличным, может существовать на уровне службы. Поскольку пользователь обычно является агрегированным корнем, а агрегированные корни живут в глобальном контексте (их ничто не «удерживает»). Я лично помещаю такую ​​логику в репозиторий или просто проверяю напрямую через ORM.

Что касается проверки использования пароля - это проблема самого пользователя, и она должна находиться под объектом User. Примерно так: 

class User{
  void Login(){
    LoggedOn=DateTime.Now;
    ...
  }
  bool HasLoggedInLast90Days(){
    return (DateTime.Now-LoggedOn).Days<=90;
  }
}

Бизнес-логика, объединяющая несколько организаций?

Совокупный корень должен управлять своими коллекциями сущностей. 

class Customer{
  void OrderProduct(Product product){
    Orders.Add(new Order(product)); //<--
  }
}

Но помните, что совокупный корень не должен микроконтролировать свои сущности.

например. это плохо: 

class Customer{
  void IsOrderOverdue(Order order){
    return Orders.First(o=>o==order)....==...;
  }
}

Вместо этого используйте: 

class Order{
  void IsOverdue(){
    return ...;
  }
}

Mapping

Я предполагаю, что отображение в dto`s live в слое обслуживания. Мои классы картирования живут рядом с классами моделей в веб-проекте.

...