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

Question

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

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

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

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

Answer 1

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

Вы можете рассмотреть только возвращающий IQueryable < Клиент > вместо IList < Клиент > из метода доступа к данным. Поскольку IQueryable <T> унаследовал от IEnumerable <T> остальное приложение должно уметь справляться с этим довольно хорошо. Вы также можете преобразовать его в список, когда вам действительно нужно.

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

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

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

Answer 2

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