Ссылки LINQ-to-SQL на объекты в других DataContexts

Question

В моих проектах баз данных я, как правило, использую "кластеры" таблиц.Эти кластеры обычно поддерживают одно приложение или группу тесно функционально связанных приложений.Часто эти кластеры также связаны друг с другом с помощью относительно небольшого количества внешних ключей;это помогает в остальном независимым приложениям в бизнесе интегрироваться друг с другом.

Так, например:представьте, что у меня есть приложения "Foo", "Bar" и "Baz", с несколькими таблицами для каждого из них.Вот список таблиц и ссылок на их внешние ключи:

• FooTable один
• Footablet два -> footablet Один
• Bartablet один -> footablet два
• BarTableTwo -> Бартабельный
• Базтабельный
• BazTableTwo -> FooTableTwo, BazTableOne

В настоящее время я использую LINQ-to-SQL для доступа к этим таблицам.У меня есть отдельный проект для каждого кластера (Foo, Bar и Baz), и каждый из этих проектов имеет .dbml для всех таблиц в кластере.Идея здесь заключается в том, что каждое (одно или несколько) приложение, использующее кластер, может импортировать общую библиотеку, содержащую необходимые ему классы LINQ.

Это может быть хорошей идеей, а может и не быть;это выглядит как присяжные заседатели является все еще вон.Что мне действительно интересно, так это могу ли я иметь ссылки между кластерами, выраженные классами в другом кластере, даже если они существуют в другом классе контекста.(И, более конкретно, как создать эту связь в Visual Studio).

Возвращаясь к примеру, я хотел бы иметь:

• Проект Foo
  • Foo.dbml
  • ФудАтакОнтекст
  • FooTable один
    • Доступно для просмотра по одному.Доступно для просмотра по двум
  • Футаблет два
    • Футаблет два.Футаблет один
    • FooTableTwo.BarTableOnes (этот не так важен)
    • FooTableTwo.BazTableTwos (эта не так важна)
• Проектная Панель
  • Bar.dbml Бар.dbml
  • Бардатаконтекст
  • Бартабельный
    • Бартабельный один.ФутАблетНый два
    • Бартабле один.Бартабле два
  • Бартаблет два
    • Бартаблет два.Бартаблет Один
• Проект Баз
  • База данных.dbml
  • Баздатаконтекст
  • Базтабельный
    • Таблица базирования одна.Таблица базирования двух
  • Baztablet два
    • Потрясающая таблетка два.Таблетка два
    • Baztablet два.baztablet Один

Изначально все ссылки на внеконтекстные объекты являются простыми идентификаторами (ints), а не объектами, а коллекции внеконтекстных объектов вообще не существуют.Я знаю, что могу добавить свои собственные методы к этим классам для выполнения соответствующего поиска (учитывая экземпляр контекста), но я хотел бы сделать вещи немного более упорядоченными и последовательными.

Обратите внимание, что при таком разделении контекстов / кластеров я получаю модульность между приложениями.Так, например, приложению Baz нужно было бы импортировать только контексты Baz и Foo (поскольку Baz зависит от Foo), но не Bar.(Это предполагает, что у меня нет коллекций объектов Bar в Foo, что меня вполне устраивает).Это хорошая вещь, но это не критично:если LINQ / VS не упростит это, я подумаю об отказе от модульности и переходе на one-big-context .

Answer 1

L2S не может моделировать взаимосвязи между файлами DBML.ИМО, это основной недостаток L2S.Я боролся с этим в нашем приложении.У нас есть все объекты в отдельных файлах DBML.Каждый файл DBML представляет пространство имен в нашем приложении и Схему в нашей базе данных SQL Server.

Итак, в итоге я сделал так: для каждой сущности, имеющей свойство, представляющее внешнюю связь в другом пространстве имен, я поместил пользовательский атрибут ассоциации к свойству в частичном классе, который имитирует атрибут ассоциации L2S.Этот пользовательский атрибут позволяет нам самим управлять взаимосвязями.Не совсем так эффективно, как это делает L2S, но у нас это работает довольно хорошо.

Рэнди