Элементы управления 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>();
    }

---

Я нашел этот похожий вопрос -> Разделение проблем с Linq To SQL и DTO

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

Я предпочитаю, чтобы Business Logic возвращала экземпляр объекта, например, Car, ICar или List (Car). Пусть DAL заполняет объект для вас. Таким образом вы поддерживаете четкое разделение между данными и пользовательским интерфейсом.

Answer 4

Мне лично нравится устанавливать мои источники данных при использовании ссылок на List<YourObject>

Answer 5

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