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

Я работал над проектом, в котором команда решила разделить домен на четыре разных файла 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. Однако создание соединения и транзакции абстрагируются, поэтому в коде есть только одно место, где сделана транзакция.

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

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

НТН.

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

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

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

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