Куда должны идти DAO в структуре проекта?

Question

Я работаю над проектом в VB.Net и мне нужно реализовать DAL. Я не совсем уверен, где в моем проекте лучшее место для размещения DAO. Стоит ли вставлять DAO в то же пространство имен, что и бизнес-объекты, которые будут их использовать. Или я должен объединить все DAO вместе.

У меня есть фон Java, который может испортить мое понимание вашего ответа .Netish. :)

Answer 1

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

Например, если у меня есть letterDAO, которое управляет постоянством букв, то я, как правило, помещаю его в ту же сборку, что и бизнес-логика буквы и сущности букв в пространстве имен, например [company]. [Project] .Letters. Таким образом, все функциональные возможности букв находятся в одном месте, и я могу легче их настроить или заменить.

Если у меня есть приложение DAO, то оно то же самое, но в разделе [компания]. [Проект]. Приложения и т. Д.

Answer 2

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

Пример: PG.CustomerCare.DAL <- Уровень доступа к данным </p>

PG.CustomerCare.BO <- Бизнес-объекты <- это может заменить Сервисы. </p>

PG.CustomerCare.Services <- Сервисы для абстрагирования бизнес-логики, будут иметь ссылку на DAL </p>

PG.CustomerCare.Client.Web <- взаимодействует только со служебным слоем </p>

PG.CustomerCare.Client.Winforms <- То же самое здесь, только взаимодействует со слоем сервиса. </p>

Answer 3

Когда речь идет о структуре и дизайне проекта на этом уровне (программирование в целом), между .NET и Java не так много различий.

При создании DAO я склонен держать их в своихсобственное пространство имен / сборка / проект в качестве сущностей.Это особенно верно, если они просто DTO s, в которых нет логики.