Управление сложностью модели .dbml LINQ to SQL

Question

Этот вопрос в некоторой степени адресован этому вопросу по LINQ to SQL .dbml передовой опыт , но я не уверен, как добавить к вопросу.

В одном из наших приложений используется LINQ to SQL, и в настоящее время у нас есть один файл .dbml для всей базы данных, управление которым становится сложным. Мы собираемся немного реорганизовать его в отдельные файлы, которые в большей степени зависят от модуля / функциональности, но одна проблема заключается в том, что многие классы высокого уровня придется дублировать в нескольких файлах .dbml, поскольку ассоциации не могут использоваться между собой. DBL-файлы (насколько я знаю), с дополнительным частичным кодом класса.

Кто-нибудь сталкивался с этой проблемой и какие рекомендации вы бы дали?

Answer 1

Воспользуйтесь настройками пространства имен. Вы можете получить к нему в свойствах, нажав на пустое пространство ORM.

Это позволяет мне иметь таблицу Users и класс User для одного набора бизнес-правил и вторую (но с тем же хранилищем данных) таблицу Users и класс User для другого набора бизнес-правил.

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

Answer 2

Я тоже написал инструмент! Мой предназначен для написания сценариев изменений в файлах dbml с использованием c #, чтобы вы могли перезапустить их и не потерять изменения. Смотрите мой блог http://www.adverseconditionals.com 4 подробнее

Answer 3

После определенного размера, вероятно, станет легче работать с xml, а не с конструктором dbml.

Answer 4

Я написал утилиту для решения именно этой проблемы, мне нужно было быстрое приложение, чтобы позволить вам выбирать только те объекты базы данных, которые вам нужны. В моем случае мне часто требовалось сложное представление, но не таблицы.

http://www.codeplex.com/SqlMetalInclude/

Answer 5

Подход, который мы использовали для хранения двух файлов .dbml. Один из них содержит Хранимые Procs, и весь доступ к производственной БД осуществляется через него. Другой находится в папке модульных тестов и содержит таблицы и их взаимосвязи и используется для манипулирования данными БД и запросов для модульных тестов.