ASP.Net MVC: лучшие практики для файлов dbml

Question

Это может быть просто вопрос типа "да" или "нет", но здесь все равно ...

Из всех (а также для большинства) примеров, которые я видел для использования mvc, видно, что метод создания файла dbml - просто перетащить в него всю схему базы данных и позволить ему автоматически генерировать все linq sql добра Похоже, что вам просто нужна одна из них (поскольку вы не можете иметь дубликаты таблиц в отдельных файлах dbml в одном проекте), но по какой-то причине может показаться, что есть лучший способ сделать это ... особенно при большой проект с большим количеством таблиц.

Так что это правильный способ создания файла dbml для использования в проекте mvc, просто перебросить всю структуру таблицы и перейти в город? Если нет, то как ты это делаешь?

Answer 1

Если бы схема была большой, я думаю, я бы полностью полагался на сценарий SQLMetal для создания моих * .dbml и вспомогательных классов. Таким образом, вы можете просто обновить всю модель данных, когда ваша база данных обновляется. В противном случае, если таблица, представление и т. Д. Будет обновлено в базе данных, вам не нужно удалять, а затем повторно перетащите эту таблицу в визуальный файл * .dbml.

На самом деле, я не эксперт по SQLMetal, но я думаю, что вы даже можете использовать его для генерации всего, что вам нужно для Linq-toSql, и даже не требовать / генерировать * .dbml файл.

Answer 2

Лично я предпочитаю создавать классы / ассоциации в .dbml, а затем генерировать базу данных из этого.

Просто добавьте следующий класс в ваш проект

partial class MyDataContext {
    partial void OnCreated() {
        if (!DatabaseExists())
            CreateDatabase();
        }
}

Answer 3

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

В этом случае следующим логическим шагом будет размещение ваших dbml-файлов / моделей в их собственных проектах по умолчанию и обучение работе с ними при такой настройке. Это также поможет повторно использовать модель базы данных, в которой у вас есть несколько приложений, взаимодействующих с этой базой данных.

Конечно, существуют проблемы с выделением вещи, а также с наличием нескольких файлов dbml в одном проекте (с точки зрения обеспечения того, что расширения классов реализуются последовательно во всех случаях, например), но у меня есть случай, когда это не неуместно.

Хороший вопрос, ответ, вероятно, имеет тенденцию быть «одним», но не в каждом случае ...