Более привлекательный по отношению к n-уровневому дизайну (BLL / DAL)

Question

У меня есть базовый логический вопрос о Даппере.

При попытке применить лучшие методики проектирования Даппер стирает грань между DAL и BLL?Многие рекомендации заключаются в том, что DAL не должен ничего знать о BLL и что DAL должен просто возвращать какой-то большой блок данных, который BLL должен преобразовать в какой-то полезный объект.

Я хотел бы узнать мнение некоторых из BLL.здесь эксперты о том, где вписывается Dapper.

Это отличный проект, и он работает очень хорошо, но, похоже, тесно связан с BLL.Я лично не против такого подхода, но мне было бы интересно, если бы 1) был лучший способ отсоединить Dapper и BLL, или 2) если это не реальная проблема, так как мы не планируем уходить от MS SQL.

Спасибо.

РЕДАКТИРОВАТЬ: в ответ на комментарий Марка:

Dapper это отличный продукт, и это ни в коем случае не удар по нему ... Что я имею в виду в сочетанииBLL заключается в том, что при выполнении запроса он обычно возвращает коллекцию определенного типа.

var dog = connection.Query<Dog>("select Age = @Age, Id = @Id", new { Age = (int?)null, Id = guid });

В этом случае запрос вернет коллекцию Dog.

Если Dapper был развернут на уровне DAL, он должен иметь ссылку наслой BLL, чтобы узнать о типах объектов, которые он собирается вернуть.

Многие рекомендации заключаются в том, что DAL никогда не должен ничего знать о BLL.Я просто пытаюсь оценить лучшую практику развертывания Dapper и сохранения хорошей структуры дизайна N-уровня.

Я знаю, что это несколько субъективно, но если этого достаточно, чтобы включить Stack Overflow, то вывсе, должно быть, нашли лучший способ развернуть его в хорошо спроектированной среде.

РЕДАКТИРОВАТЬ: заметил, что тип "Dog" не был показан в примере запроса из-за символов HTML.

Снова отредактируйте в ответ на комментарии Хогана: суть моего вопроса больше связана с идеей о том, что строка кода выше будет в DAL.Для ясности, мы можем предположить, что у нас есть решение с DAL и BLL как отдельные проекты класса.Теперь, когда эта строка кода добавляется в проект DAL, DAL должен будет ссылаться на BLL, чтобы получить объект "Dog".Это взаимная зависимость в порядке?или просто то, как Даппер чаще всего используется?Или это плохая практика и просто не лучший способ использовать Dapper?Я знаю, что многие «пуристы» сказали бы, что DAL не должен ничего знать о BLL… полагаться на объект «Dog» в приведенной выше строке нарушит этот принцип.Тем не менее, приведенная выше строка является наиболее распространенным примером использования Dapper.

Answer 1

Думайте о dapper как Стойка для баз данных, читайте: http://samsaffron.com/archive/2012/01/16/that-annoying-insert-problem-getting-data-into-the-db-using-dapper

Dapper не собирается заставлять вас использовать репозитории или какие-то конкретные шаблоны.

Он не скажет вам, куда поместить вашу бизнес-логику. Если вы хотите запутать свою бизнес-логику кодом доступа к данным, пусть будет так. Если нет, не надо. Дэппер агностик. Это простая технология доступа к данным.

Answer 2

Мы используем Dapper в наших хранилищах / слоях данных как быстрый и простой способ привязать наши данные к нашим объектам без написания дополнительного кода для сопоставления.Вы сами решаете, хотите ли вы использовать DTO для передачи ваших данных между слоями или отображения непосредственно на ваши сущности (BO), которые могут находиться в отдельном общем слое.

Все зависит от уровня абстракции, которыйВы хотите реализовать.Если вы используете Entity Framework и делаете запросы LINQ непосредственно на бизнес-уровне, то вы тесно связываете свою логику с EF, и ваши объекты также используются на вашем уровне данных и бизнес-уровне.

Answer 3

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

Позвольте мне привести несколько примеров, основанных на приведенной выше строке кода, чтобы прояснить мою точку зрения.

Если бы я читал исходный код проекта и обнаружил эту строку кода в файле * .aspx.cs, я бы немного огорчился. Проект не является n-уровневым или модульным.

И наоборот, если бы я читал источник и обнаружил эту строку кода в файле с именем dog.cs в подкаталоге DAL проекта, было бы ясно, что этот код предназначен для доступа к данным для объектов собаки в решение.

Аналогичный вывод можно сделать, если он находился в каталоге вызова BLL.

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