Я работаю над веб-приложением .Net 3.5. В нем есть различные модули, например, «Клиенты», «Заказы» и т. Д. Мне нужно спроектировать уровень доступа к данным (DAL) для этого с использованием Enterprise Library 4.0 ( используя блок приложения доступа к данным (DAAB) для подключения к SQL Server 2005. Вот как я планирую это сделать:
• Иметь интерфейс с именем «IDataService». Он будет иметь такие элементы, как «ExecuteReader ()», «ExecuteScalar ()», «ExecuteNonQuery ()», «AddParams» и т. Д., В основном, этот интерфейс будет выглядеть почти как у DAAB.
• Иметь класс с именем «DataService», который реализует этот интерфейс. Этот класс будет действовать как обертка над DAAB, и каждый из методов будет использовать соответствующий метод в DAAB для внутреннего использования.
• иметь бизнес-классы (или контейнеры данных), такие как Customer, Data и т. Д., Свойства которых будут сопоставляться с соответствующими атрибутами таблиц в базе данных.
• Наличие классов DAL для каждого модуля, такого как CustomerDataService, OrdersDataService и т. Д. Каждый из этих классов будет иметь код конструктора, в котором я буду создавать экземпляр класса DataService, как показано ниже: IDataService dataService = new DataService () Кроме того, каждый из этих классов будет иметь такие методы, как: GetCustomerDetails () AddCustomer () RemoveCustomer () UpdateOrder и т. д. Эти методы будут внутренне использовать объект «dataService» для выполнения любой операции над базой данных ExecuteReader, ExecuteNonQuery и т. д.
• Иметь класс сопоставления для каждого модуля, такого как «CustomerMapper», «OrderMapper» и т. Д. Этот класс будет принимать источник данных (например, IDataReader) в качестве входных данных и заполнять данные в общей коллекции (List). И эти классы отображения будут внутренне вызываться соответствующим классом Dataservice для возврата коллекции безопасного типа вызывающему клиенту.
• Наличие вспомогательного класса, такого как DbHelper, который будет выполнять такие задачи, как «обработка случаев DBNull», «хранение имен хранимых процедур» и т. Д.
• Классы DataService будут внутренне использоваться классами слоя BusinessLogic ... т.е. CustomerBusiness, OrdersBusiness и т. Д.
• Уровень бизнес-логики вернет коллекцию на уровень представления.
Имеет ли этот дизайн смысл? Каковы преимущества / недостатки этого подхода? Преимущество такого подхода заключается в том, что все классы DataService всегда будут программироваться в соответствии с интерфейсом «IDataService» без необходимости знать, как класс «DataService» реализован внутри. Так что в будущем, если я удалю DAAB и использую другой API внутри моего Класс DataService, код клиента не нужно менять.
Кроме того, я могу добавить любой метод в моем интерфейсе IDataService, которого нет в DAAB .... например BatchUpdate () ...
Пожалуйста, поправьте меня, если я ошибаюсь.