Linq to Sql - несколько файлов .DBML или один файл .DBML - PullRequest
29 голосов
/ 23 февраля 2010

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

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

  • Клиент
  • Производитель
  • Сотрудник
  • Заказ клиента

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

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

Спасибо

Ответы [ 4 ]

11 голосов
/ 23 февраля 2010

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

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

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

6 голосов
/ 23 февраля 2010

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

2 голосов
/ 23 февраля 2010

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

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

НТН.

0 голосов
/ 23 февраля 2010

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

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

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

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

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