Использование шаблона репозитория в ASP.NET MVC с БД SQL Server;как смоделировать репозиторий, чтобы его модуль тестировался без нарушения OOD

Question

Я изучал инфраструктуру ASP.NET MVC, используя книгу Стивена Сандерсона «Pro ASP.NET MVC Framework». С этой целью я пробовал несколько вещей в проекте, с которым я не настолько знаком, но это то, что я должен делать, а именно:

• Использование шаблона репозитория для доступа к моей базе данных и заполнения моего домена / бизнес-объектов.
• Используйте интерфейс для хранилища, чтобы его можно было смоделировать в тестовом проекте.
• Использовать инверсию управления для создания моих контроллеров

У меня есть веб-приложение MVC, библиотека доменов, библиотека тестов.

В моей базе данных мои доменные элементы имеют Id, представленный в виде столбца int identity. В моих классах домена сеттер является внутренним, так что только репозиторий может установить его.

Итак, мои проблемы / проблемы:

1. По сути, все классы в доменной библиотеке могут устанавливать свойство Id, что не подходит для ООП, поскольку они должны быть доступны только для чтения.
2. В моей тестовой библиотеке я создаю поддельное хранилище. Однако, поскольку это другая сборка, я не могу установить свойства Id для классов.

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

Answer 1

Разве вы не можете установить идентификаторы своих объектов во время создания и сделать их доступными только для чтения, вместо того, чтобы устанавливать идентификаторы с помощью метода установки?

Или вам нужно установить идентификатор в другое время. Если это так, не могли бы вы объяснить, почему?

EDIT:

Можно ли развести ID и объект домена? Нужно ли знать что-либо, кроме хранилища, идентификатор?

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

Таким образом, идентификаторы объектов домена являются теми, какими решит реализация репозитория - они могут быть целыми числами из базы данных, URL-адресов или имен файлов.

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

Есть что-нибудь, что помешало бы вам использовать этот шаблон?

Answer 2

вы можете использовать атрибут InternalsVisibleTo . Это позволит увидеть типы из сборки в тестах (при условии, что они находятся в разных сборках).

В противном случае вы можете оставить свойство доступным только для чтения для внешних объектов, но в то же время иметь конструктор, который имеет параметр ID и задает свойство ID. Тогда вы можете вызвать этот конструктор.

Надеюсь, это поможет.