Linq to SQL, Entity Framework, шаблон репозитория и внедрение зависимостей

Question

Видео Stephan Walters на MVC и Models - очень хорошее и легкое обсуждение различных тем, перечисленных в заголовке этого вопроса. Один вопрос, указанный в примечаниях без ответа, был:

Если вы создаете шаблон Interface / Repository для Linq2SQL, вызывает ли классы Linq2SQLs зависимость от Linq, даже если вы передаете классы как toList?

Вероятно, это простой ответ ДА, однако, какую стандартную механику вы бы использовали для представления данных?

Допустим, у вас есть объект Product, который состоит из трех таблиц (Цены, Текст и Фотографии) (у вас могут быть наборы цен для разных регионов, разный текст для локализации и разные фотографии). (Походит на образец строителя) Вы могли бы создать часть этих таблиц, собирая правильные цены, текст и фотографии в единый Список? Поскольку списки могут быть проприетарными, вы бы использовали объект Dictionary?

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

Еще один быстрый вопрос: готов ли Entity Framework к сложной базе данных? Есть много конструкций, которые Linq2SQL любит, а EF нет. EF, кажется, требует идентификационные поля в качестве первичных ключей (HAHA), но кажется, что каждая демонстрация делает это. Я хочу использовать EF, но мне постоянно не удается заставить его работать, возвращаясь к Linq2SQL.

Answer 1

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

В этом смысле репозиторий возвращает полностью сформированные объекты «Продукт» со всеми связанными с ними данными «Цена», «Текст» и «Фото». Это называется Совокупным Корнем.

Не должно быть проблем со списками, так как они являются объектами CLR.

Что касается EF для сложных сценариев, мой совет еще не был бы, по причинам, которые вы заметили.

Answer 2

Стандартный механизм, который я бы использовал для представления данных, - это объект передачи данных. Я бы никогда не возвратил объект LINQ to SQL или Entity Framework через границу службы, и я не решился бы вернуть его через границу уровня любого вида. Это потому, что эти объекты будут сериализовать зависящие от реализации данные.