LINQ to SQL: несколько/один .dbml для каждого проекта?

Ответ 1

Обратите внимание, что LINQ2SQL предназначен для простого и простого способа обработки отношений с объектами.

Не нарушайте связь таблицы и единицы концепции работы, создавая несколько файлов .dbml.

Если вам когда-либо понадобится создать несколько файлов .dbml(которые я не рекомендую), попробуйте выполнить следующее: -

• Если вы создаете несколько баз данных без взаимосвязи между этими таблицами базы данных.
• Если вы хотите использовать один из этих .dbml только для обработки хранимых процедур
• Если вам не нужна концепция единицы работы.

Если ваша база данных слишком сложна, я бы рассмотрел ORM, такой как NHibernate, EF 4

Ответ 2

По-моему, вы можете разбить файлы .dmbl, чтобы каждый из них содержал подмножество таблиц /procs из БД в зависимости от функции и отношения. Я еще не сделал этого, так что это просто мнение.

Однако я создал несколько файлов .dbml, чтобы помочь в модульном тестировании. Если вы работаете в среде, которая ограничивает использование хранимых процедур в рабочей среде, вы не можете использовать таблицу .dbml(вы можете использовать часть proc). Поэтому, если вы "unit test" (это действительно интеграционное тестирование), уровень БД вашего кода вы можете вызвать обертку proc, а затем проверить результаты, запросив таблицы через интерфейс .dbml. В таких случаях я разбиваю файл .dmbl только на таблицы, которые я хочу запросить в своем "unit test".

Дополнительная информация: У меня есть 2 решения, которые я создаю. Один из них имеет модульные тесты и никогда не строится на сервере сборки. Другая построена на сервере сборки и развернута для тестирования/производства.

Ответ 3

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

Это связано с тем, что dbml mapps к вашим таблицам и почему не просто использовать один "соединитель данных" / "слой данных" для этого, кажется странным/странным дизайном для использования более чем одного.

Это, вероятно, более управляемо, используя только 1.

Ответ 4

Этот вопрос был тщательно проанализирован здесь: http://craftycode.wordpress.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/

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

Ответ 5

Скажем, у вас есть база данных:

База данных D содержит таблицы A, B, C, X, Y, Z, где

• Таблица A имеет внешний ключ связь с таблицами B и C
• Таблица X имеет внешний ключ связь с таблицами Y и Z
• Таблица X также имеет отношение внешнего ключа к таблице A

Скажем, у вас есть 2 файла DBML P и Q на основе базы данных D

• DBML файл P содержит объекты A ', B' и C ', где A' связано с B ' и C 'через ассоциации.
• Файл DBML Q содержит сущности X ', Y' и Z ', где X 'соединен с Y' и Z 'через ассоциации.

AFAIK, нет возможности для файлов DBML P и Q содержать связь между объектами A 'и X'. Это самая большая проблема с наличием нескольких файлов DBML.

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

Возвращаясь к нашему примеру, если между таблицами A и X в базе данных D не было никакой связи, тогда можно было бы создать 2 файла DBML.

В общем случае можно иметь несколько файлов DBML, если каждый DBML файл содержит все сущности и отношения, которые связаны. Обратите внимание, что обратное не является проблемой, т.е. Может быть один DBML файл, содержащий несколько групп сущностей, которые не связаны друг с другом никакими ассоциациями.

Ответ 6

Ответ сложный, потому что это то, что требует ситуация. Я пытаюсь логически отделить каждый DBML в контекстах (в конце концов, DBML предоставляет функциональность DataContext). Поэтому, если мое приложение имеет один контекст, то для меня нет смысла иметь отдельный DBML для каждой таблицы. Контекст - это король при создании ваших файлов DBML, что я говорю.

Ответ 7

Еще одна вещь, которую следует иметь в виду, заключается в том, что LINQ использует DataContext для отслеживания идентификаторов экземпляров создаваемых ими объектов. Следовательно, объект, представляющий строку в таблице, созданной одним экземпляром класса DataContext, не совпадает с созданным другим, даже если все свойства одинаковы.

Если у вас есть несколько файлов DBML, то по необходимости будет несколько экземпляров DataContexts, по одному для каждого файла DBML. Следовательно, сущности не могут соединяться или разделяться из одного DataContext в другой.

Это применимо, если сущность существует в обоих (или всех) DBML файлах.

Ответ 8

Да, хм, я прочитал подробный анализ в craftycodeblog, но не было бы неплохо, если бы вы могли получить все преимущества с обеих сторон?

Я хочу иметь один DataContext для моего приложения, но все же разбить его на несколько файлов .dbml(и несколько файлов dbml.layout и designer.cs). Я предполагаю, что это не поддерживается Visual Studio, но это решит все проблемы.

Пример использования: большое приложение состоит из нескольких модулей, каждый из которых добавляет набор приложений (и, конечно, код) к приложению (то есть к одной базе данных) и имеет доступ к коду и таблицы других модулей.

Пусть скажем, модуль ABC определяет таблицы A, B, C, а модуль XYZ определяет таблицы X, Y, Z. Таблицы XYZ могут иметь внешние ключи к таблицам ABC. Было бы лучше, если бы: * При работе с кодом модуля ABC вы видите "только" таблицы ABC, как в дизайнере, так и в редакторе linq. * При работе с кодом модуля XYZ вы можете видеть только таблицы XYZ в дизайнере dbml, чтобы вы уменьшили беспорядок и увидели только схему вашего модуля. Редактор linq должен иметь доступ к таблицам ABC и XYZ.