Наша команда прошла все эти посты для нашего проекта (~ 600 таблиц). Большим предостережением для моего ответа здесь является то, что мы еще не завершили проект, поэтому не все обучение имело место. Я могу предложить только то, что мы узнали до сих пор.
По сути, то, что вы хотите сделать, невозможно реалистичным способом (в настоящее время, о котором я знаю).
Наши требования заключались в том, чтобы иметь возможность использовать визуальный конструктор (не обязательно дизайнер Visual Studio) и не нужно взламывать кучу автоматически сгенерированных файлов (или создавать инструменты для автоматического взлома файлов), потому что это просто рецепт катастрофы во многих отношениях.
В итоге мы получили два возможных решения, отметив, что нам действительно нужно было логическое группирование таблиц:
Используйте конструктор в LLBLGen (примечание: не бесплатен для коммерческого использования), который может логически разделить таблицы на разные «представления» базы данных
Разделение таблиц на бизнес-подмножества (т. Е. Продажи, отчеты и т. Д.), При этом перекрывающиеся таблицы повторяются с использованием разных имен и, возможно, различного набора столбцов в каждом поддомене.
На нашем этапе тестирования нам очень понравился дизайнер LLBLGen; однако варианты генерации кода вызывают головокружение (определенно написанное программистом для программистов), и вывод оставляет желать лучшего (с моей первой попытки он генерировал код, который не компилировался). Если вы готовы вложить несколько долларов в свой проект и потратить некоторое время на тестирование, я все равно рекомендую вам попробовать его сами (есть бесплатная пробная версия); Как я уже сказал, дизайнер довольно хороший, и, читая в Интернете, кажется, есть много историй успеха.
Излишне говорить, что мы выбрали последнее решение. Это сработало для нас, потому что в нашей бизнес-модели, когда у нас есть «общая» таблица, во всех, кроме одной из моделей поддоменов, эта таблица доступна только для чтения, и мы не беспокоимся о распространении изменений между всеми моделями поддоменов (т. Е. нам нужно только определенное представление данных из каждого субдомена). Это может быть не то же самое для вас. Это дополнительные затраты на обслуживание, если вы начинаете вносить радикальные изменения в базовую схему, но поскольку вы работаете с устаревшей базой данных, это, вероятно, не будет иметь место. Мы решили, что компромисс стоил того, чтобы сохранить инструмент в нашей существующей среде разработки. (Примечание: мы используем слегка модифицированный текстовый шаблон POCO для генерации самих классов сущностей. Если ничего другого, эта часть была действительно хорошим решением.)
Всего ~ 200 таблиц, я бы сказал , попробуйте , собрав их в одну модель, даже в качестве эксперимента. Вы определенно захотите использовать для этого свою самую мощную коробку разработки ... Когда мы попробовали это с нашей моделью (EF 4.0), нам пришлось убить ее в середине процесса.
Во время наших чтений мы видели некоторые грохоты о поддержке "представлений" модели непосредственно в конструкторе Visual Studio. Если бы это существовало, мы бы обязательно его использовали. Как бы то ни было, я подозреваю, что такая функция находится на заднем плане. Проекты с 200 таблицами - определенно ниша по сравнению с проектами с 100 таблицами или менее, которые действительно не нуждаются в такой возможности.