Многоуровневые и определяемые пользователем формы

Question

Мы разрабатываем наш новый продукт, который будет включать в себя многоквартирные дома. Он будет написан на ASP.NET и C# и может быть размещен на Windows Azure или в другом облачном решении.

Мы смотрим на MVC и другие технологии, и, честно говоря, мы увязли в различных акронимах (MVC, EF, WCF и т. Д.).

Особое требование нашего приложения вызывает головную боль - пользователи смогут добавлять поля в базу данных или даже создавать совершенно новый модуль.

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

(Добавление полей и т. Д. В систему будет осуществляться с использованием веб-интерфейса).

Все хорошо и хорошо, но проблема возникает при создании модели данных для MVC. Изменение модели данных программно добавить поле к таблице, кажется, невозможно, по этой ссылке:

Create EDM during runtime?

Это главная головная боль для нас. Даже если мы не используем MVC, я думаю, что мы все равно хотим создать модель данных (возможно, для LINQ to SQL).

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

Конечно, нам не нужно использовать MVC или Entity Framework, но мне кажется, что это те технологии, которые Microsoft направит нас на будущее развитие.

Любые мысли? Я предполагаю, что мы не первые люди в мире, которые рассматривают эту идею настраиваемого пользователем приложения.

Answer 1

Прежде чем вы начнете просматривать настраиваемую схему, убедитесь, что вы полностью изучили возможность создания таблиц типов «Name-Value Pair», как описано здесь http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_nvp . Также не забывайте, что вам придется предоставлять гораздо более высокие разрешения для ваших учетных записей sql, чтобы они могли создавать таблицы «на лету». Настраиваемая схема означает, что вашим учетным записям sql также потребуются гораздо более высокие разрешения. Было бы нецелесообразно назначать эти более высокие разрешения учетной записи арендаторов, но отдельной учетной записи обеспечения, которая может выполнять эти задачи.

Также, прежде чем инвестировать в EF - попробуйте googling 'EF Vote of No Confidence'. Он был поднят (я считаю) в основном в ответ на более ранние версии, но его, безусловно, стоит прочитать. nHibernate - альтернатива, заслуживающая внимания.

Answer 2

Сверху моей головы это звучит как плохая идея, позволяющая пользователям изменять схему базы данных. Я думаю, что вам не хватает слоя абстракции. На мой взгляд, было бы правильнее использовать базу данных для хранения данных, описывающих формат данных клиента. Фактические данные затем будут сохранены в текстовом столбце как xml, включая информацию о версии. Это решение может не соответствовать вашим потребностям, но я не знаю деталей вашего проекта. Так что просто рассмотрите мои 5 центов.