Шаблон репозитория: Добавить элемент

Question

Просто нужно уточнить это, если у меня есть интерфейс ниже

public interface IRepository<T>
{
    T Add(T entity);
}

при реализации проверяет дублирование, если сущность уже существует до того, как будет сохранена, это все еще работа Репозитория, или она должна обрабатывать кое-где еще?

Answer 1

Да - я рекомендую делать эти проверки в хранилище.

Длинный ответ: термин «хранилище» немного расплывчат, но он все больше используется в качестве имени уровня абстракции персистентности. Название хорошее, но оно не говорит слишком много: если вы берете Asp.Net MVC в качестве примера, примеры приложений, таких как Neirds ужин и т.п., или проекты codeplex инкапсулируют доступ к данным с помощью класса репозитория. Если такой уровень реализован с помощью реляционной базы данных для экземпляра, первичные ключи таблиц не допускают дублирования записей, что означает, что в этом случае реализация репозитория выдаст исключение, если вставлены 2 записи с одинаковым ключом. Другими словами, RDBMS-реализация репозитория будет всегда из-за этой проверки, вы не сможете ее избежать. Поэтому, чтобы сделать поведение репозиториев в мире наиболее похожим и избежать неожиданностей, давайте все сделаем эту проверку.

Второй вопрос: следует ли уже указывать в бизнес-логике, что ваш метод Add () не связан с уже существующей записью. Иногда имеет смысл решить эту проблему только в одном месте, например, в базе данных, из-за проблем с параллелизмом или из-за экономии туда-обратно. С другой стороны, например, приятно как можно скорее сообщить пользователю, что имя пользователя уже занято. Так что это зависит.

хорошего дня

Answer 2

По сути, решение о том, где рассматривать этот случай, зависит от ваших точных требований.

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

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

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

Answer 3

Если объект уже существует, вы можете либо сгенерировать исключение, либо обновить поля существующего объекта.

Если вы выберете последнее, метод, вероятно, должен называться примерно так: AddOrUpdate()

Пример Linq to SQL

Если я получаю одну запись, я буду использовать

public Entity GetEntity(int entityID)
{
    return dataContext.Entities.SingleOrDefault(e => e.EntityID = entityID);
}

... И в вызывающем методе я проверю, является ли возвращенное значение нулевым, прежде чем пытаться использовать возвращенную сущность.

Если я обновляю запись, я извлеку сущность, как показано, отредактирую сущность, а затем вызову метод репозитория UpdateEntity(entityID) для обновления полей в базе данных.

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

Public void InsertEntity(Entity entity)
{
    dataContext.Entities.InsertOnSubmit(entity);
    dataContext.SubmitChanges();
}

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