LINQ к SQL: Несколько / Единственный .dbml на проект?
Вместо flex-flow: row wrap; попробуйте flex-direction: column;. Это заставляет каждый элемент двигаться вертикально. Затем оберните все, что вы хотите, в одну «строку» внутри своей собственной .code-block, чтобы сохранить содержимое каждой строки вместе. Итак,
<div class="code-block">
<div class="line-break">
<div class="terminal">while(</div>
<div class="code-block">true</div>
<div class="terminal">)</div>
</div>
... и так далее для остальных.
(Тебе тоже не нужно align-items: baseline;.)
7 ответов
Обратите внимание, что LINQ2SQL предназначен для простого и удобного способа управления отношениями базы данных с объектами.
Не нарушайте отношения таблиц и концепции единиц работы, создавая несколько. dbml файлы.
Если вам когда-либо понадобится создать несколько файлов .dbml (что я не рекомендую), попробуйте выполнить следующее: -
- Если вы создаете несколько баз данных без связи между этими таблицами базы данных.
- Если вы хотите использовать один из этих .dbml только для обработки хранимых процедур
- Если вас не волнует концепция единицы работы.
Если ваша база данных слишком сложна, я бы рассмотрел ORM, например NHibernate, EF 4
По-моему, можно разделить .dmbl файлы так, чтобы каждый содержал подмножество tables/procs от DB согласно функции и отношениям. Я еще не сделал этого, таким образом, это - просто мнение.
Я однако создал несколько .dbml файлов для помощи с поблочным тестированием. Если Вы работаете в среде, которая ограничивает Вас использованием сохраненного procs в Вашей продуктивной среде затем, Вы не можете использовать часть таблицы .dbml (можно использовать proc часть хотя). Таким образом, если Вы "модульный тест" (это - действительно интеграционное тестирование) уровень DB Вашего кода можно назвать proc обертку и затем проверить результаты путем запросов таблиц через интерфейс .dbml. В случаях как это я разделю .dmbl файл на просто таблицы, которые я хочу запросить в своем "модульном тесте".
Дальнейшая информация: у Меня есть 2 решения, которые я создаю. Каждый имеет модульные тесты и никогда не основывается на сервере сборки. Другой основан на сервере сборки и развернут на тесте/производстве.
Я сказал бы, Вам всегда просто нужен 1 dbml-файл Для каждой базы данных. Если Вы имеете многочисленные связи к другим базам данных, рассматриваете дизайн или используете отдельные dbml-файлы. Так или иначе каждый достаточно для каждой базы данных.
Это, потому что dbml mapps к Вашим таблицам и почему не только используют один "коннектор данных" / "слой данных", для который, кажется нечетным / странный дизайн для использования больше чем одного.
Это - вероятно, больше управляемого использования только 1 также.
Ответ хитер, потому что это - то, чего требует ситуация. Я пытаюсь логически разделить каждый DBML на контексты (в конце концов, DBML обеспечивает функциональность DataContext). Таким образом, если мое приложение имеет единственный контекст, то не имеет смысла для меня иметь отдельный DBML для каждой таблицы. Контекст является королем, когда создание Ваших файлов DBML - то, что я говорю.
Допустим, у вас есть база данных:
База данных D содержит таблицы A, B, C, X, Y, Z, где
- Таблица A имеет внешний ключ связь с таблицами B и C
- Таблица X имеет внешний ключ связь с таблицами Y и Z
- Таблица X также имеет отношения внешнего ключа с таблицей A
Допустим, у вас есть 2 файла DBML P и Q на основе базы данных D
- Файл P DBML содержит объекты A ', B' и C ', где A' соединен с B ' и C 'через ассоциации.
- Файл DBML Q содержит объекты X ', Y' и Z ', где X 'подключен к Y' и Z 'через ассоциаций.
AFAIK, у файлов P и Q DBML нет возможности содержать ассоциацию между объектами A 'и X'. Это самая большая проблема, связанная с наличием нескольких файлов DBML.
На мой взгляд, файл DBML отражает модель данных, представленную таблицами и ограничениями на эти таблицы в базе данных. Если некоторые таблицы или ограничения отсутствуют в наборе файлов DBML, то набор файлов DBML неточно отражает базовую базу данных.
Возвращаясь к нашему примеру, если не было связи между таблицами A и X в базе данных D , тогда можно будет создать 2 файла DBML.
Вообще говоря, можно иметь несколько файлов DBML, если каждый файл DBML содержит все связанные сущности и отношения. Обратите внимание, что обратное не является проблемой, т. Е.
Еще одна вещь, о которой следует помнить, - это то, что LINQ использует DataContext для отслеживания идентификаторов экземпляров создаваемых им сущностей. Следовательно, сущность, представляющая строку в таблице, созданную одним экземпляром класса DataContext, не совпадает с сущностью, созданной другим, даже если все свойства одинаковы.
Если у одного есть несколько файлов DBML, то по необходимости , будет несколько экземпляров DataContexts, по одному для каждого файла DBML. Следовательно, объекты нельзя объединять или совместно использовать из одного DataContext в другой.
Это применимо, когда объект существует в обоих (или во всех) файлах DBML.
Эта проблема была подробно проанализирована здесь: http://craftycode.wordpress.com/2010/07/19/linq-to-sql-single-data-context-or-multiple/
Таким образом, вы должны создать не более одного контекста данных для сильно связанная группа таблиц или один контекст данных для каждой базы данных.