Должны ли объекты бизнес-логики знать о своих объектах данных LINQ-to-SQL?

Question

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

Для разделения проблем я пытаюсь каким-то образом сопоставить свои бизнес-объекты с логикой с объектами данных LINQ to SQL в файле .dbml (довольно новый для этого, кстати).Однако это выглядит так, что моим бизнес-объектам нужно будет знать о соответствующих объектах LINQ2SQL.Я читал эта статья о попытке использовать POCOs с помощью файла сопоставления xml, и, похоже, это похоже на то, что я хочу, за исключением того, что у меня нет однозначного сопоставления таблиц с классами из-за отношения "многие ко многим", для которого мне нужно было создать дополнительную таблицу.

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

Как я могу разделить эти слои?

Answer 1

Не уверен, что вы каким-то образом привязаны к LINQ to SQL, но то, чего вы пытаетесь достичь, в значительной степени используется по умолчанию в NHibernate.Я рекомендую взглянуть на NHibernate, чтобы понять, было бы проще переключиться, чем бороться с LINQ на SQL.

Я обнаружил, что бороться с инструментом - почти всегда плохая идея.