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

Question

Я прочитал статью Рика Страля о Linq to SQL DataContext Lifetime Management в надежде найти ответы на некоторые вопросы о том, как мне управлять своими файлами .dbml, поскольку они так тесно связаны с DataContext. К сожалению, статья Рика, похоже, сфокусирована на времени жизни DataContext во время выполнения , и мой вопрос касается того, как файлы .dbml должны быть организованы в время разработки .

Здесь был задан общий вопрос «Лучшие практики с использованием .dbml» , на который был дан ответ , и ответы были сосредоточены на внешних инструментах для управления .dbml.

Я задаю более сфокусированный вопрос , когда и почему у не должен быть один файл .dbml в вашем проекте на основе LINQ to SQL ?

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

Answer 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 не точно отражает базовую базу данных.

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

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

Answer 6

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

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

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

Answer 7

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