Создать сложную модель базы данных с MS Entity Framework

Question

У меня есть база данных с примерно 160 таблицами (это шок! Я думал, что у нее было около 50 ...).
Мы используем кодовую базу без DAL, и мы хотим начать использовать MS Entity Framework (этопоследняя, ​​самая горячая вещь в .net DAL, верно?), чтобы мы могли использовать Linq и другие современные технологии 3 года назад.

Я попытался автоматически сгенерировать всю модель БД,но это кажется кошмаром для использования и изменения.Например, у него есть несколько таблиц, которые не связаны автоматически (возможно, модель БД отсутствует в нескольких областях).

Затем я попытался сгенерировать каждую «область» базы данных в отдельности, но мне мешали две точки.

Прежде всего, для требуется отдельная строка подключения для каждой модели.WTF.Кроме того, у нас есть клиенты с разными базами данных, и поддержка 10 строк подключения для 30 клиентов станет кошмаром.

Во-вторых, кажется, что он не может связываться с классами в других моделях.Может я просто не нашел это?Приблизительно с 10-15 «модулями», большинство из которых связаны друг с другом, это может победить одну из целей объединенного DAL.Например, у нас есть таблица «file», связанная с контактами, техподдержкой, продуктами, Интернетом и т. Д. Мы все еще можем использовать идентификаторы, но это довольно грустно.

Итак, что быты сделаешь ?Одна огромная модель, которую очень сложно создать и поддерживать;или несколько меньших, которые легче обновлять, но немного сложнее в повседневной работе?Что вы используете, и каковы положительные и отрицательные стороны?

Answer 1

Во-первых, о строках соединения, да, каждой модели нужна своя строка соединения, потому что это EntityConnection , которая содержит не только информацию о том, как подключиться к базе данных, но и информацию онайдите 3 части вашей модели во время выполнения (например, SSDL , CSDL и MSL ).Таким образом, при работе с одной базой данных даже часть строки соединения с базой данных одинакова, но часть Метаданные различна для каждой модели, и поэтому вам необходимо, чтобы они все были там.

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