Как использовать одну и ту же таблицу в нескольких моделях?

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

По сути, то, что вы хотите сделать, невозможно реалистично (в настоящее время, насколько я знаю).

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

Мы пришли к двум возможным решениям, отметив, что нам на самом деле нужна логическая группировка таблиц:

• Используйте конструктор в LLBLGen (примечание: платный для коммерческого использования), который может логически разделить таблицы на разные «представления» базы данных

• Разделите таблицы на бизнес-подмножества (например, продажи, отчеты и т. д.), при этом перекрывающиеся таблицы повторяются с разными именами и, возможно, с другим набором столбцов в каждом поддомене.

На этапе тестирования нам очень понравился дизайнер LLBLGen; тем не менее, параметры генерации кода просто головокружительны (определенно написаны программистом для программистов), а результат оставлял желать лучшего (при моей первой попытке он сгенерировал код, который не компилировался). Если вы готовы вложить несколько долларов в свой проект и потратить некоторое время на тестирование, я бы все же рекомендовал вам попробовать его самостоятельно (есть бесплатная пробная версия); как я уже сказал, дизайнер довольно приятный, и, читая в Интернете, кажется, есть много историй успеха.

Излишне говорить, что мы выбрали последнее решение. Это сработало для нас, потому что в нашей бизнес-модели, когда у нас есть «общая» таблица, во всех моделях поддоменов, кроме одной, эта таблица доступна только для чтения, и мы не беспокоимся о распространении изменений между всеми моделями поддоменов (т.е. нам нужно только определенное представление данных из каждого субдомена). Это может быть не тот случай для вас. Если вы начнете вносить радикальные изменения в базовую схему, это потребует дополнительных затрат на обслуживание, но, поскольку вы работаете с устаревшей базой данных, этого, вероятно, не произойдет. Мы решили, что компромисс стоил того, чтобы сохранить инструменты в нашей существующей среде разработки. (Примечание: мы используем слегка измененный текстовый шаблон POCO для создания самих классов сущностей. По крайней мере, эта часть была действительно хорошим решением.)

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

Во время наших чтений мы заметили некоторые слухи о поддержке «представлений» модели непосредственно в конструкторе Visual Studio. Если бы это существовало, мы бы обязательно его использовали. Однако, как бы то ни было, я подозреваю, что такая функция находится на втором плане. Проекты на 200 столов определенно являются нишевыми по сравнению с проектами на 100 столов или меньше, которым такая функция на самом деле не нужна.

Простое решение — просто изменить имя объекта в модели.
Вы можете добавить контекст в качестве префикса к имени объекта, и это решит вашу проблему.

Просто выбросьте это, если вы все еще готовы что-то попробовать, но пробовали ли вы поместить модели в разные сборки?

например: Все таблицы заказов в модели в MyProject.Data.Sales Все управление клиентами в модели в MyProject.Data.Customers и т. д.

Поскольку они находятся в разных пространствах имен, они не будут конфликтовать таким образом, и вы сможете иметь столько их, сколько захотите. Вам просто нужно правильно ссылаться на них, когда вы хотите их использовать.