Насколько изощренным должен быть DAL? - PullRequest
Новая
       8

Насколько изощренным должен быть DAL?

4 голосов
/ 31 мая 2010

По сути, DAL (Уровень доступа к данным) должен обеспечивать простые методы CRUD (Создание / Чтение / Обновление / Удаление), но у меня всегда есть соблазн создать более сложные методы, чтобы минимизировать обходы доступа к базе данных из уровня бизнес-логики.

Что вы думаете о следующих расширениях CRUD (большинство из них в порядке, я полагаю):

  1. Чтение: GetById, GetByName, GetPaged, GetByFilter ... e.t.c. методы
  2. Create: GetOrCreate методы (сущность модели возвращается из БД или создается, если она не найдена и не возвращается), Create (множество связей) вместо Create и множественные вызовы методов AssignTo
  3. Обновление: Объединение методов (список сущностей обновляется, создается и удаляется за один вызов)
  4. Удалить: Удалить (bool children) - необязательные дочерние удаления, Очистка методы
  5. Методы установки: DAL отвечает за заполнение пустой базы данных предопределенными словарными сущностями

Где вы обычно реализуете возможности Entity Cache? DAL или BLL? (Мой выбор - BLL, но я также видел реализации DAL)

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

Заранее спасибо!

Ответы [ 2 ]

1 голос
/ 31 мая 2010

Я не уверен, что «изощренное» - правильное слово, оно действительно зависит от того, что вы определяете как «бизнес-логика», и от того, что вы поддерживаете в чистоте Разделение проблем .

Чтение: GetById, GetByName, GetPaged, GetByFilter ... e.t.c. методы

Как и вы, я бы назвал все это Чтением, и я думаю, что они в порядке (в частности, GetById). Некоторые из более темных, которые у вас есть, вероятно, тоже хороши, если они ориентированы на данные.

RE Caching: я делал это в основном в BL, хотя я не вижу причин, почему вы не могли бы сделать это в DAL, если это было подходящим . Если у вас есть куча клиентов, колотящих хранилище данных, и данные меняются не слишком часто - тогда, конечно, почему бы и нет.

RE Граница: На ум приходит пара вещей.

  • Я всегда абстрагирую своего фактического поставщика доступа к данным за интерфейсом (); если вы гарантируете, что этот интерфейс очищен от зависимостей (то есть: он будет одинаково хорошо работать для источников данных MS SQL, Oracle, MySQL и NoSQL), то вы на правильном пути - как только вы введете что-либо, специфичное для технологии DAL, в Интерфейс, который вы знаете, что делаете что-то не так (если вы находитесь в .net универсальных типах, таких как DataTables, это хорошо, IMHO).
  • Когда вы разрабатываете BL, вы должны иметь представление о размере приложения и вероятных узких местах; следовательно, нет никаких причин, по которым вы не можете быть умными о том, как устроен BL (и это DAL). Поэтому, когда вы сталкиваетесь с бизнес-задачей, которая, как вы знаете, будет забита, возвращает много данных и т. Д. Я думаю, что было бы неплохо рассмотреть вопрос о разработке методов, которые бы эффективно справлялись с ней. Вы можете спроектировать интерфейс как с «объемными», так и со многими меньшими запросами, которые делают одно и то же - таким образом, вы покрываете разные случаи использования. Да, это приведет к снижению удобства обслуживания, но это частично смягчается, если заранее продумать / спроектировать его (немного похоже на то, как вам нужно внедрить систему безопасности в приложение, а не пытаться добавить ее позже в качестве запоздалой мысли) .

Наконец ( imporant ) - вещь в BL в том, что, хотя она часто сложна, она также специфична для приложения / службы, над которой вы работаете; сами данные могут иметь свои собственные правила, и иногда их лучше применять на уровне данных, а не в отдельных приложениях.

1 голос
/ 31 мая 2010

Я думаю, он должен быть таким же сложным, как и , вам нужно, чтобы он был .

Вероятно, самый простой способ справиться с этим - создать некоторый базовый класс (в зависимости от вашей среды, это может быть абстрактный класс с методами, требующими переопределения), который имеет самые основные методы CRUD, например,

  • Найти все - вернуть список
  • Найти по первичному ключу
  • Сохранить (мои предпочтения - создать или обновить. Если объект помечен как новый, то это создание, в противном случае обновление)
  • Удалить по объекту или первичному ключу

Помимо этого, подкласс для каждого конкретного объекта для таких вещей, как

  • Найти по имени
  • Удалить по дате
  • и т.д.. и т.д.

... но все это должно оставаться исключительно доступом к данным. Любой вид применения бизнес-правил (вы обычно знаете, когда начнете помещать заявления и менять дела), должен оставаться на бизнес-уровне.

...