Linq to Sql - Несколько файлов .DBML или один файл .DBML

Я работаю над веб-приложением, используя ASP.NET 3.5. Приложение имеет сотни таблиц. Мне сказали на семинаре, что я должен использовать один .DBML файл для всего приложения, а не использовать несколько файлов .DBML(также было сообщение в stackoverflow, в котором говорилось то же самое). Учитывая, что у меня так много таблиц, использование одного файла .DBML имеет смысл или мне лучше создать несколько файлов .DBML, которые логически сгруппированы?

Например, я думал о создании следующих файлов .DBML:

Клиент
Vendor
Сотрудник
Заказ клиента

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

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

Спасибо

Ответ 1

Я бы посоветовал вам использовать файл ONE dbml для всех ваших таблиц.

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

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

Ответ 2

Я работал над проектом, так как команда решила отделить домен в четырех разных файлах DBML. Основная причина этого переплеска связана с конструктором LINQ to SQL. Конструктор не был построен для использования с большими доменами.

Эти четыре "поддомены" в этом проекте были достаточно раздельными, но было некоторое совпадение, и это все время било нас. Используя этот опыт, я бы посоветовал вам использовать один DBML файл для каждого домена. Обычно у вас есть один домен для каждой базы данных, поэтому это означает один DBML файл для каждой базы данных.

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

using (var con = new SqlConnection("constr"))
{
    con.Open();
    using (var tran = con.BeginTransaction())
    {
        using (var context = new CustomerDataContext(con))
        {
            // do some work with it
            context.SubmitChanges();
        }

        using (var context = new VendorDataContext(con))
        {
            // do some work with it
            context.SubmitChanges();
        }
    }
}

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

Ответ 3

У меня довольно большой проект с 200 таблицами или около того, и он отлично работает в одном контексте данных; так как все данные довольно взаимосвязаны (спроектированы между 2-й и 3-й нормальной формой), было бы больно использовать несколько контекстов данных.

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

НТН.

Ответ 4

Я бы использовал один DBML файл для каждого контекста. В контексте я подразумеваю операцию, которую должен выполнять ваш пользователь, поскольку он/она находится в одном конкретном окне вашего приложения. Например:

У вас есть GUI, позволяющий управлять объектами вашего Клиента; Тогда я бы подумал о наличии CustomerManagementDataContext, в котором я бы добавил таблицы для задач управления клиентами, связанных с ними, и всех зависимостей.

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

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