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

Question

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

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

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

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

Answer 1

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

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