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

Недавно я запустил новый проект веб-форм и решил отделить бизнес-классы от любых ссылок на 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), и какие другие проблемы я могу решить в ходе реализации проекта.

Источник

2 ответа

Решение

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

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

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

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

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

Источник

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

Источник
Другие вопросы по тегам