Разделение проблем с Linq To SQL и DTO

Question

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

(from c in dataContext.Customers
where c.Active == true 
select new DTO.Customer
{
   CustomerID = c.CustomerID,
   Name = c.CustomerName,
   ...
}).ToList()

Хотя создание объектов DTO добавляет работы, это похоже на лучший подход к тесной связи между уровнями Business и Data и означает, что я могу протестировать уровень Business без присутствия базы данных.

У меня вопрос: это хорошая практика? Есть ли способ генерирования DTO (может быть, через SQLMetal), и какие еще проблемы я могу решить в ходе реализации проекта.

Answer 1

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

Возможно, вы захотите просто вернуть IQueryable вместо IList из вашего метода доступа к данным. Так как IQueryable наследует от IEnumerable , остальная часть вашего приложения должна быть в состоянии справиться с этим довольно хорошо. Вы также можете преобразовать его в список, когда вам это действительно нужно.

Преимущество этого состоит в том, что вы можете довольно легко динамически изменять запрос и минимизировать объем данных, возвращаемых с SQL Server.

например. если подпись вашего метода IQueryable GetCustomers () вы можете получить одного клиента, вызвав GetCustomers (). Где (c => c.CustomerID == 101) .Single ();

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

Answer 2

По моему мнению, в большинстве случаев объекты DTO не нужны при работе с LINQ. Сгенерированные классы LINQ могут быть легко протестированы. LINQ дает вам возможность запрашивать ваши данные из разных источников, используя идентичные запросы. Это дает вам возможность проверять ваши запросы по спискам объектов вместо реальных БД.