Сложный модуль на основе создания новой записи в БД с ASP.NET MVC 2
У меня есть очень сложная проблема, которую я должен решить, и я много думал и искал и пришел к одному выводу, который я упомяну ниже. проблема в том, что у меня есть клиент, который хочет создавать веб-сайты на основе общей функциональности, поэтому давайте назовем его модулями, поэтому я подумал о том, чтобы использовать переносимые области MVC Contrib, которые являются отличной идеей для подключения модулей, но у меня есть большая проблема, скажем, я создал модуль блога, который будет реализован на новом сайте, который он хочет, теперь у некоторых пользователей есть уникальные требования, например, одному из них нужно добавить галерею картинок в каждую статью или список ссылок в каждой статье. это было бы легко в обычной ситуации, когда у вас есть один сайт для работы, поэтому все, что вам нужно сделать, это
- добавьте новую таблицу галереи с внешним ключом в таблицу блогов.
- восстановить код Linq2SQl и обновить модель.
- добавить новые элементы формы в Create, Edit, Delete Views .
- добавить логику в контроллер
но в моей ситуации это сложно и время громоздко из-за 2 причин
- если новый функционал классный и клиент решит внедрить его на всех сайтах, то мне придется повторить работу для каждого сайта.
- если функциональность уникальна, это создаст для меня несогласованность в будущем
вот почему в качестве первого шага для решения проблемы я использовал Portable Areas для создания аддонов для каждого модуля, теперь это определенно облегчит мою работу, перетаскивая 1 DLL для каждого нового модуля или аддона, но у меня есть небольшая проблема, которая
- Поскольку новый модуль или надстройка представляет собой Dll, как я могу создать такую функцию в панели "Мой администратор" для установки нового надстройки или найти любой новый добавленный модуль / надстройка, перетаскивая новые DLLS в главное приложение
- Что является наилучшей практикой для создания процедуры установки внутри переносимой области, такой как обновление базы данных, новые маршруты и т. Д.
Теперь перейдем к самой большой проблеме, специфичной для модуля Addon:). Давайте вернемся к аддону Gallery Gallery. Если я буду следовать упомянутой выше логике, создав ее в качестве переносимой области, будет проще создать функциональность в модуле. Код для циклического прохождения всех установленных аддонов и перечисления их в представлениях CRUD, но поскольку я изолировал аддон и не хочу вручную обновлять код основного модуля по причинам, изложенным выше, не будет никакого способа выполнять операции CRUD для новых аддонов в синхронизации с основным модулем, потому что нет связи с внешним ключом, опять же, потому что, как я сказал выше, она может быть необязательной, поэтому я подумал о следующем решении, которое, я надеюсь, будет лучшим
Сначала в процессе установки я создам таблицу для дополнения галереи, но вместо создания отношения внешнего ключа я создам внешний ключ вручную, который заполняется генерацией уникального идентификатора в контроллере основного модуля при создании записи с использованием следующий код затем сохраните его в ViewData и просто передайте его в Addon Controller, когда я создаю новую запись,
private string GenerateId()
{
long i = 1;
foreach (byte b in Guid.NewGuid().ToByteArray())
{
i *= ((int)b + 1);
}
return string.Format("{0:x}", i - DateTime.Now.Ticks);
}
ViewData["FK"] = GenerateId();
но вот мои опасения
- Это возможно или просто глупо.
- Именно эта техника будет генерировать действительно уникальный ключ.
Мне очень жаль, если мой вопрос хромает, но это лучшее место, чтобы спросить, и я думаю, что многие люди хотели бы иметь такую функциональность и надеюсь, что кто-то ответит мне
1 ответ
Я думаю, что это отличный вопрос. Некоторое время назад я начал работать над проектом CMS с использованием MVC1, где я хотел поддерживать плагины. У меня было так, что администратор мог поместить новую сборку плагина в папку bin, и при следующем запуске приложения он сканировал все сборки на наличие IPlugin (или что-то еще) и загружал их. Я встроил частичные виды в сборку плагина, чтобы все было автономно. каждому плагину был присвоен уникальный идентификатор, когда он был размещен на странице, и контроллер плагина знал, как использовать этот идентификатор для запроса собственной таблицы (хранилища) своих данных. основное приложение ничего не знало о схеме плагина.
единственное отличие здесь заключается в том, что, похоже, у вас будет несколько сайтов, работающих в одной базе данных, и вам нужно различать, какие экземпляры плагина вам нужны для каждого сайта. Я предполагаю, что где-то у вас есть ключ, который указывает, какой это веб-сайт, который можно использовать с помощью внешнего ключа, чтобы выбрать только плагины для этого веб-сайта для страницы, на которой находится пользователь.
Я не уверен, что это ответ, я просто думаю вслух. надеюсь, это немного поможет обсуждению.
РЕДАКТИРОВАТЬ: Чтобы автоматически загружать плагины, я использовал возможность NInject сканировать сборки для IM-модулей. Мой IPlugin наследуется от Ninject.Modules.INinjectModule
и все плагины реализуют интерфейс IPlugin. Затем при запуске приложения у меня есть следующая строка:
kernel.Load( "*.Plugin.dll" );
где ядро - это Ninject.IKernel, и эта строка будет сканировать любую сборку, соответствующую этому шаблону файла, поэтому я могу добавить сборку, такую как Weather.Plugin.dll.