DAL дизайн вопрос

Question

Мне нужно спроектировать слой доступа к данным. Библиотека приложения DAL .Net Enterprise версии 3.5. Блок доступа к данным (DAAB). В моем приложении есть различные логические модули, такие как регистрация, выставление счетов, управление заказами, управление пользователями и т. Д. Я использую бизнес-объекты C # для сопоставления объектов модуля с таблицами базы данных, а затем возвращаю коллекцию List клиенту.

Я хотел бы спроектировать свой DAL таким образом, чтобы, если завтра мы решим использовать какую-то другую среду доступа к данным, у нас будет минимальное изменение кода. Учитывая это, как мне спроектировать структуру моего класса? Я думал, что у меня будет класс DbManagerBase, который будет оберткой над существующим .net DAAB Этот класс DbManagerBase будет реализовывать интерфейс с именем IDbManagerBase, который будет иметь открытые методы, такие как ExecuteReader, ExecuteNonQuery и т. Д.

Клиентский класс т.е. RegistrationDAL, UserManagermentDAL будет иметь следующий код внутри каждого из своих методов: IDbManagerBase obj = new DbManagerBase () obj.ExecuteReader (myStoredProcName) , , , Это хороший OOPS дизайн? Могу ли я узнать какой-нибудь лучший подход, пожалуйста? Или мне нужно использовать наследование здесь? Могу ли я иметь все методы в классе DbManagerBase и классах RegistrationDAL, UserManagermentDAL как статические? Я думаю, если у меня есть методы как статические, то приведенный выше интерфейсный код не будет иметь никакого смысла ... правильно ???

Answer 1

Чтобы по-настоящему абстрагировать DAL, я бы использовал шаблон хранилища .

Answer 2

Чтобы ответить на несколько вопросов:

Могу ли я иметь все методы в Класс DbManagerBase и RegistrationDAL, UserManagermentDAL классы как статические?

Я бы, вероятно, выбрал нестатический подход, поскольку он дает гибкость для лучшего управления созданием DAL (например, вы можете создавать их экземпляры на фабрике), а также позволяет иметь два DAL на месте которые разговаривают с разными БД более чистым способом. Также вам не нужно будет создавать экземпляр DbManagerBase в каждом объекте, поскольку он будет членом экземпляра.

Относительно IDbManagerBase, имеющего ExecuteReader, ExecuteNonQuery и obj.ExecuteReader (myStoredProcName)

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

Другой момент заключается в том, что перед тем, как приступить к реализации DAL, я обязательно прочитал бы некоторый код в других DAL с открытым исходным кодом, таких как NHibernate или Subsonic. Вполне возможно, что они решат вашу бизнес-задачу и значительно сократят время разработки.

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