Я читаю о слоях приложений и хочу использовать этот дизайн в моем следующем проекте (c #, .Net). Некоторые вопросы:
Делается ли разделение слоев через пространства имен? Project.BLL. Что бы то ни было, Project.DAL. Что бы то ни было
Более уместно разделить по слоям, а затем по компонентам (Project.BLL.Component1) или по компонентам, а затем по слоям (Project.Component1.BLL)
Для моего DAL, этот слой далее организован, используя различные классы? Если все вызовы базы данных помещены в один класс, организации не существует. Было бы лучше разделить их на разные классы или пространства имен?
Классы DAL обычно статичны? Кажется обременительным создавать экземпляр объекта DAL перед каждым вызовом одного из его методов.
Любые другие советы для правильной работы с этими слоями приветствуются.
источник
На вопросы 1 и 2 ответьте с ответами Мэтью.
Я потратил много времени, пытаясь найти лучший способ структурировать DAL настольных приложений. И лучший способ действительно зависит от потребностей приложения. В одном из моих приложений я пошел по пути создания класса DA для каждой таблицы базы данных, который регистрировался с помощью центрального (то есть одноэлементного) класса DataProvider и обрабатывал CRUD. Каждый класс DA мог бы затем решить, хочет ли он кэшировать все данные таблицы в ОЗУ или нет (производительность!) И / или должен ли он иметь возможность запускать автоматические обновления клиентов на других клиентах, работающих на других компьютерах (например, многопользовательский) параллелизм). Это позволяет легко добавлять новые классы DAL, поскольку все, что им нужно сделать, это соответствовать интерфейсу регистрации.
Не каждому DAL требуется такая функциональность, но я узнал, что сам подход (т. Е. Поставщик одноэлементных данных и простые классы DAL со статической регистрацией) значительно облегчил мою жизнь, когда я начал добавлять новые классы.
Я определенно не рекомендовал бы встраивать CRUD в классы более высокого уровня, если только это не очень простое приложение. DAL - это абстракция хранилища данных. Если вы решите изменить свое хранилище данных в будущем (даже если будет использоваться только MySQL вместо MS SQL), вы будете очень благодарны за это. Плюс: объекты BLL должны быть структурированы по их отношениям бизнес-логики. Объекты DAL структурированы по типам контейнеров хранения, которые они представляют. Различия могут быть драматичными.
Как НЕ сделать ваши классы DAL статическим. То, что вы получаете в скорости кодирования, вы многократно потеряете в тестируемости и гибкости.
источник