Шаблон репозитория: добавьте объект
Просто потребность разъяснить этого, Если я имею ниже интерфейса
public interface IRepository<T>
{
T Add(T entity);
}
при реализации его, делает проверку дублирование, если объект является уже существующим, прежде чем сохранятся, это - все еще задание Репозитория, или это еще должно обработать некоторых где?
3 ответа
Да - рекомендую выполнить эти проверки в репозитории.
Длинный ответ: термин «репозиторий» немного расплывчат, но он все чаще используется в качестве имени уровня абстракции сохраняемости. Название хорошее, но не говорит слишком многого: если вы возьмете Asp.Net MVC в качестве примера, образцы приложений, такие как ужин Neirds и ему подобные, или проекты codeplex инкапсулируют доступ к данным с помощью класса репозитория. Если такой уровень реализован с реляционной базой данных для экземпляра, первичные ключи таблиц не позволят дублировать записи, что означает, что в этом случае реализация репозитория вызовет исключение, если будут вставлены 2 записи с одним и тем же ключом. Другими словами, РСУБД-реализация репозитория всегда будет требовать этой проверки, вы не сможете ее избежать. Итак, чтобы сделать поведение репосториев в мире наиболее похожим и избежать сюрпризов, позвольте им всем выполнить эту проверку.
Это второй вопрос, следует ли вам поддерживать уже в бизнес-логике, чтобы ваш метод Add () не ассоциировался с уже существующей записью. Иногда имеет смысл решить эту проблему только в одной точке, например в базе данных, из-за проблем с параллелизмом или экономии двусторонних обращений. С другой стороны, например, приятно как можно скорее сообщить пользователю, что имя пользователя уже занято. Так что это зависит от обстоятельств.
хорошего дня
Если объект уже существует, вы можете либо вызвать исключение, либо обновить поля существующего объекта.
Если вы выберете последнее, метод, вероятно, следует называть как-то вроде AddOrUpdate ()
Пример Linq to SQL
Если я получаю одну запись, я буду использовать
public Entity GetEntity(int entityID)
{
return dataContext.Entities.SingleOrDefault(e => e.EntityID = entityID);
}
... И в вызывающем методе я проверю, является ли возвращаемое значение null, прежде чем пытаться использовать возвращенный объект.
Если я обновляю запись, я извлечу сущность, как показано, отредактирую сущность, а затем вызову метод репозитория UpdateEntity (entityID) для обновления полей в базе данных.
Если я добавляю запись, это еще проще. Поскольку это база данных, а мои таблицы всегда содержат поле Identity типа int (по сути, автоматически назначаемое число), добавление записи - самая простая операция из всех (это всегда новая запись):
Public void InsertEntity(Entity entity)
{
dataContext.Entities.InsertOnSubmit(entity);
dataContext.SubmitChanges();
}
Бизнес-правила (например, адреса электронной почты уникальны) могут обрабатываться в репозитории или на отдельном бизнес-уровне. Если вы ищете наиболее «правильный» путь, я думаю, большинство людей согласятся, что бизнес-правила принадлежат их собственному уровню бизнес-логики.
По сути, решение о том, где рассматривать этот случай, зависит от ваших конкретных требований.
Если у вас есть бизнес-правила, которые определяют четкие действия, когда это происходит, например, если существует дубликат, новый элемент следует переименовать, а затем его можно встроить в класс репозитория.
С другой стороны, если действуют более сложные правила, согласно которым, например, требуется дополнительная информация для изменения элемента перед добавлением, то его следует обрабатывать дальше по пищевой цепочке.
Концепция репозитория гласит, что он существует для выполнения действий с сохранением состояния. Так что, если вы можете делать все это в репозитории, ничего страшного. Если вы обнаружите, что начинаете ссылаться за пределами репозитория или ваш репозиторий имеет зависимости, например, вызов другого репозитория, службы или менеджера (или любой другой номенклатуры процессоров, которую вы предпочитаете), то это хороший знак вернуться на шаг назад.