доступ к данным в DDD?
Как будто вы пытаетесь получить доступ к объекту, который является null. Рассмотрим ниже пример:
TypeA objA;
. В это время вы только что объявили этот объект, но не инициализировали или не инициализировали. И всякий раз, когда вы пытаетесь получить доступ к каким-либо свойствам или методам в нем, он будет генерировать NullPointerException, что имеет смысл.
См. Также этот пример:
String a = null;
System.out.println(a.toString()); // NullPointerException will be thrown
6 ответов
Методы выхода CRUD должны быть частью Репозитория... выход. Но я думаю, что необходимо спросить, почему у Вас есть набор методов CRUD. Что они действительно делают? Для чего они действительно? Если Вы на самом деле вызываете, доступ к данным копирует Ваше использование приложения, я думаю, что он делает репозиторий намного более полезным и мешает Вам иметь, чтобы сделать хирургию ружья, когда определенные типы изменений происходят с Вашим доменом.
CustomerRepo.GetThoseWhoHaventPaidTheirBill()
// or
GetCustomer(new HaventPaidBillSpecification())
// is better than
foreach (var customer in GetCustomer()) {
/* logic leaking all over the floor */
}
"Сохраните" методы типа, должна также быть часть репозитория.
Если у Вас есть совокупные корни, это мешает Вам иметь взрыв Репозитория или иметь логику, распространенную на всем протяжении: у Вас нет 4 x # шаблонов доступа к данным объектов, просто те Вы на самом деле используете на совокупных корнях.
Это составляет мои.02$.
DDD обычно предпочитает шаблон репозитория по активному рекордному шаблону, на который Вы намекаете с Клиентом. Сохранить.
Одна оборотная сторона в модели Active Record - то, что она в значительной степени предполагает единственную модель персистентности, запрещая некоторый особенно навязчивый код (на большинстве языков).
Интерфейс репозитория определяется в доменном слое, но не знает, хранятся ли Ваши данные в базе данных или нет. С шаблоном репозитория я могу создать InMemoryRepository так, чтобы я мог протестировать доменную логику в изоляции и использовать внедрение зависимости в приложении, чтобы иметь уровень служб, инстанцируют SqlRepository, например.
Многим людям, имея специальный репозиторий только для тестирования звуков глупо, но если Вы используете модель репозитория, можно найти, что Вам действительно не нужна база данных для Вашего конкретного приложения; иногда простой FileRepository будет добиваться цели. Свадьбе с собой к базе данных перед знанием Вас, нужен он, потенциально ограничивает. Даже если база данных необходима, это намного быстрее для запущения тестов против InMemoryRepository.
Если у Вас нет многого в способе доменной логики, Вам, вероятно, не нужен DDD. ActiveRecord довольно подходит для большого количества проблем, особенно если у Вас есть главным образом данные и просто определенная логика.
Давайте отступим в течение секунды. Evans рекомендует, чтобы репозитории возвратили совокупные корни и не просто объекты. Так предполагая, что Ваш Клиент является совокупным корнем, который включает Заказы, затем при выборке клиента из его репозитория заказы пришли с ним. Вы получили бы доступ к заказам путем навигации по отношениям от Клиента к Заказам.
customer.Orders;
Таким образом для ответа на вопрос операции CRUD присутствуют на совокупных корневых репозиториях.
CustomerRepository.Add(customer);
CustomerRepository.Get(customerID);
CustomerRepository.Save(customer);
CustomerRepository.Delete(customer);
Я сделал это оба способа, о которых Вы говорите, Мой предпочтительный подход теперь является персистентным неосведомленным (или PONO - Плоскость Ole'.Net Object) метод, где Ваши доменные классы только волнуются по поводу того, чтобы быть доменными классами. Они ничего не знают о том, как они сохраняются или даже если они сохраняются. Конечно, необходимо время от времени быть прагматически настроены об этом и допускать вещи, такие как идентификатор (но даже затем я просто использую слой, супер вводят, который имеет идентификатор, таким образом, у меня может быть единственная точка где вещи как живое значение по умолчанию),
Главная причина для этого состоит в том, что я стремлюсь следовать за принципом Единственной Ответственности. Следующим этот принцип я нашел свой код намного более тестируемым и удобным в сопровождении. Также намного легче внести изменения, когда они необходимы, так как у меня только есть одна вещь думать о.
Одной вещью быть осторожным является чрезмерное увеличение размера метода, от которого могут пострадать репозитории. GetOrderbyCustomer.. GetAllOrders.. GetOrders30DaysOld.. и т.д. и т.д. Одно хорошее решение этой проблемы состоит в том, чтобы посмотреть на шаблон Объекта Запроса. И затем Ваши репозитории могут просто взять в объекте запроса выполниться.
Я также настоятельно рекомендовал бы изучить что-то как NHibernate. Это включает много понятий, которые делают Репозитории так полезными (Карта идентификационных данных, Кэш, объекты Запроса..)
Раздражающая вещь с Применением Nilsson DDD&P состоит в том, что он всегда запускает с, "Я не сделал бы этого в приложении реального мира, но...", и затем его пример следует. Назад к теме: Я думаю OrderRepository. GetOrdersByCustomer (клиент) является способом пойти, но существует также обсуждение Списка рассылки ALT.Net (http://tech.groups.yahoo.com/group/altdotnet/) о DDD.
Даже в DDD, я разделил бы классы Доступа к данным и стандартные программы от Объектов.
Причины,
- Тестируемость улучшается
- Разделение проблем и Модульной конструкции
- Более удобный в сопровождении в конечном счете, поскольку Вы добавляете объекты, стандартные программы
Я не эксперт, просто мое мнение.