Я пытаюсь создать модель, которую можно динамически строить «на лету» на основе таблицы SQL. Я не буду заранее знать таблицу SQL, поэтому модель должна быть динамической. Слишком много возможных таблиц, чтобы было возможно предварительно построить модель для каждой из них. Я хотел бы, чтобы пользователь мог пройти, выбрать таблицу из списка, а затем на основе этой таблицы была сгенерирована модель. Мы будем очень благодарны за любое понимание или направление. Спасибо
Вы понимаете, что добавление класса (Model) потребует перестройки приложения? Вы думали о разработке Entity Framework DB First?
Это довольно широкий вопрос, поэтому вот такое же широкое предложение (не ответ): многие CMS (например, Sitefinity) позволяют создавать собственные типы контента для Интернета. Затем он создаст своего рода документ схемы, который будет сохраняться и загружаться каждый раз при запуске приложения, чтобы иметь возможность ссылаться на таблицы. Они используют открытый доступ как ORM. Я не уверен, является ли эта функция функцией открытого доступа или они просто надстраиваются на нее. Другие CMS должны делать аналогичные вещи ("на лету" типы контента). Все такие созданные модели должны будут наследоваться от одного и того же типа для CRUD.





Я могу придумать несколько немного разных подходов. Все будут рассматривать генератор кода (например, инструмент текстового шаблона T4)
Один из подходов, который мы использовали, заключался в отображении всех определений столбцов и таблиц в отдельных собственных таблицах в базе данных. Это не обязательно, поскольку вы можете использовать Information_Schema базы данных для получения информации, необходимой для простой модели. Но! Как только вам понадобится дополнительная информация (это более вероятно) для столбцов и таблиц, я бы подумал о том, чтобы сопоставить их как собственные Datarecords в собственных таблицах.
Под конкретным я подразумеваю под определением столбца и таблицы информацию, необходимую для создания моделей. Например. Таблица DialogColumn имела такие столбцы, как Columnname (nVarchar), displayname (nVarchar), recordhistory (bit), UID_Dialogtable и некоторые другие «метаданные», которые представляли свойство модели. Таблица, давайте назовем ее также Dialogtable, а затем все свойства, например. имя таблицы, отображаемое имя, onsavingscript и т. д.
Обладая этой информацией, вы можете создавать машинные обертки в виде моделей. предпочтительно создавать их на предварительном этапе процесса сборки компилятора или только один раз (в зависимости от вашей архитектуры). Для расширения и изменения структуры модели вы можете написать отдельный инструмент, который управляет записью таблицы и столбцов в базе данных за вас и компилирует нужную вам сборку.
и так далее и тому подобное
Модель обычно строго типизирована и поэтому известна во время сборки. Кто ваши пользователи? Разработчики или пользователи приложений?