элементы управления формами Windows и LINQ;Что мне вернуть?

Question

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

Прямо сейчас я возвращаю 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

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

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

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

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

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