В моих проектах баз данных я обычно использую «кластеры» таблиц. Эти кластеры обычно поддерживают одно приложение или группу тесно связанных между собой приложений. Часто эти кластеры также связаны друг с другом через относительно небольшое количество внешних ключей; это помогает интегрировать друг с другом независимые бизнес-приложения.
Итак, например: представьте, что у меня есть приложения «Foo», «Bar» и «Baz» с несколькими таблицами для каждого из них. Вот список таблиц и их ссылки на внешние ключи:
- FooTableOne
- FooTableTwo -> FooTableOne
- BarTableOne -> FooTableTwo
- BarTableTwo -> BarTableone
- BazTableOne
- BazTableTwo -> FooTableTwo, BazTableOne
В настоящее время я использую LINQ-to-SQL для доступа к этим таблицам. У меня есть отдельный проект для каждого кластера (Foo, Bar и Baz), и каждый из этих проектов имеет .dbml для всех таблиц в кластере. Идея заключается в том, что каждое (одно или несколько) приложений, использующих кластер, может импортировать общую библиотеку, содержащую необходимые ему классы LINQ.
Это может быть, а может и не быть хорошей идеей; это похоже на жюри это по-прежнему out. Что мне действительно интересно, так это то, могу ли я иметь ссылки между кластерами, выраженные классами в другом кластере, даже если они существуют в другом классе контекста. (И, более конкретно, как создать эту связь в Visual Studio).
Возвращаясь к примеру, хотелось бы иметь:
- Project Foo
- Foo.dbml
- FooDataContext
- FooTableOne
- FooTableOne.FooTableTwos
- FooTableTwo
- FooTableTwo.FooTableOne
- FooTableTwo.BarTableOnes (это не так важно)
- FooTableTwo.BazTableTwos (это не так важно)
- Project Bar
- Bar.dbml
- BarDataContext
- BarTableOne
- BarTableOne.FooTableTwo
- BarTableOne.BarTableTwos
- BarTableTwo
- BarTableTwo.BarTableOne
- Project Baz
- Baz.dbml
- BazDataContext
- BazTableOne
- BazTableOne.BazTableTwos
- BazTableTwo
- BazTableTwo.FooTableTwo
- BazTableTwo.BazTableOne
Вне контекста все ссылки на сущности вне контекста являются простыми идентификаторами (целыми числами), а не объектами, а коллекции сущностей вне контекста вообще не существуют. Я знаю, что могу добавить свои собственные методы к этим классам для выполнения соответствующих поисков (с учетом экземпляра контекста), но я хотел бы сделать вещи немного более упорядоченными и последовательными.
Обратите внимание, что при таком разделении контекстов / кластеров я получаю модульность между приложениями. Так, например, приложение Baz должно будет импортировать только контексты Baz и Foo (поскольку Baz зависит от Foo), но не Bar. (Это предполагает, что у меня нет коллекций сущностей Bar в Foo, что меня устраивает). Это хорошо, но не критично: если LINQ / VS не упрощает эту задачу, я подумаю об отказе от модульности и использовании одного большого контекста.
