Элементы управления Windows Form и LINQ; Что я должен вернуть?

Question

При работе с элементами управления Windows Form и LINQ есть «лучший вариант» для того, как ваш Buisiness Layer возвращает данные?

Прямо сейчас я возвращаю DataTables, чтобы затем установить DataSource в возвращаемый DataTable. Есть ли лучший вариант? Зачем?

public class BLLMatrix 
{ 
    public static DataTable GetMaintItems(int iCat) 
    { 
     IQueryable<tblCaseNotesMaintItem> tItems = DALMatrix.GetCNTable(); 
     return 
      (tItems.Where(item => item.CategoryID == iCat & item.IsActive).OrderBy(item => item.OrderID).Select(
       item => new { item.ItemID, item.ItemDescription })).CopyLinqToDataTable(); 
    } 

internal static class DALMatrix 
{ 
    internal static MatrixDataContext MatrixDataContext = new MatrixDataContext(); 

    internal static Table<tblCaseNotesMaintItem> GetCNTable() 
    { 
     return MatrixDataContext.GetTable<tblCaseNotesMaintItem>(); 
    } 

---

Я нашел подобный вопрос ->Separating concerns with Linq To SQL and DTO's

Answer 1

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

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

DataSets полезны, но их недостаток безопасности во время компиляции (не в случае сильно типизированных DataSet) из-за цифрового доступа на основе строк может представлять собой проблему.

Как правило, при сериализации DataSets по проводу по сравнению с объектом передачи данных также возникает большое количество накладных расходов.

Answer 2

Мне нравится создавать собственные классы моделей из-за накладных расходов DataSets. Если вы возвращаете массив объектов (или все, что реализует интерфейс IList), вы все равно можете установить значение, равное свойству DataSource большинства элементов ASP.NET.

Answer 3

Я лично хотел бы установить свои DataSources при использовании ссылки на List<YourObject>

Answer 4

Я предпочитаю бизнес-логики, чтобы вернуть экземпляр объекта, например автомобиля, ИКАР или List (автомобиль) Пусть DAL заполнить объект для вы. Таким образом, вы сохраняете четкое разделение между данными и пользовательским интерфейсом.

Answer 5

Мне нравится использовать DataReaders, а не набор данных, и я использую блок итератора в слое данных, чтобы включить datareader в IEnumerable<IDataRecord>. Оттуда у меня есть своего рода дополнительный шаг между бизнес-слоем и уровнем данных, чтобы перевести этот IEnumerable в IEnumerable<MyBusinessObject>. Вы также сможете передать это на слой презентации для привязки данных.

Мне нравится этот подход, потому что он лучше справляется с разделением данных и бизнес-слоев: бизнес-уровень не должен мыслить с точки зрения наборов данных, а на уровне данных не нужно знать, как создавать бизнес-объекты. Если я думаю об этом как о отдельном уровне, я получаю лучшее из обоих миров. Изменение либо уровня данных, либо уровня бизнеса означает, что мне нужно только изменить заводский код, который создает мои бизнес-объекты.