LINQ to SQL DAL + BLL + Презентация

Question

Я новичок в LINQ to SQL и имею следующую настройку для простого приложения:

1) сгенерированные классы LINQ to SQL из таблиц моей базы данных (DAL?)

2) созданные классы (BLL?), Которые используют текст данных LINQ to SQL, для вставки, обновления, удаления, выбора

3) в моем уровне представления, например, при вставке. новый «продукт», я создаю новый экземпляр объекта «продукт», который происходит из моего уровня DAL (это то, что LINQ to SQL создал для меня)

У меня вопрос, если это правильный путь для разделения слоев в этом случае. Что странно для меня, это то, что я использую тип объекта, который был определен в DAL, который не должен использоваться на уровне представления, если вы спросите меня. Но если я хочу использовать объекты LINQ to SQL без повторного создания новых объектов, это похоже на путь.

Что вы посоветуете по этому поводу? Я новичок в LINQ, поэтому я не уверен, что здесь лучше всего.

спасибо за помощь

Answer 1

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

• Поддержка отложенной загрузки (хотя следите за проблемой 1: N)
• У вас есть один набор сгенерированных сущностей (хотя и с поддержкой datacontext)

Однако, для более тяжелой, более пуристической архитектуры, вы можете рассмотреть

• Обертывание артефактов Linq2SQL в шаблон репозитория
• Отобразите сущности L2SQL в POCO, прежде чем возвращать их на свой BLL / Уровень обслуживания
• В зависимости от вашей сетевой архитектуры и архитектуры представления вам также может понадобиться рассмотреть, как ваша сущность выглядит в сети (сериализация, WCF, JSON и т. Д.), И вы также можете взглянуть на Просмотр моделей , в которых Если ваша сущность несколько раз «меняет» класс и форму, когда она отображается и преобразуется между слоями.
• На самом деле, вы можете рассмотреть другой ORM, нежели Linq2SQL, например. NH или EF

EDIT: У вас есть пара опций, если вы не хотите работать с объектами L2SQL, сгенерированными VS, в вашем BLL или уровне представления.

• Создайте новый набор POCO и затем отобразите объекты L2SQL в вашем хранилище / dal. Automapper может упростить эту задачу.

• Вы можете использовать свои собственные POCO непосредственно в Linq2SQL, предоставив XmlMappingSource , хотя это немного больше работы.