Как лучше всего создавать портал и модули ASP.NET? - PullRequest
1 голос
/ 09 сентября 2010

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

Во время сбора наших требований по различным запросам мы заметили, что между основными аспектами запросов есть некоторое общее основание.Между проектами некоторые пользователи были разделены, а некоторые - нет, некоторые роли пользователей менялись между процессами, 2 приложения обращались к одним и тем же данным, 2 из них обращались к данным клиента.Индивидуальные запросы далеки от тривиальных.

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

Мой вопрос заключается в том, как лучше всего разработать такуюпортал в среде asp.net, IIS 6, MSSQL 2005.Я думал о создании одного пула приложений в IIS, который будет использоваться для всех модулей и портала.Создайте портал и каждый модуль как отдельные веб-приложения, а модули развертывания - в подпапках приложения портала.Порталу просто нужно будет предоставлять ссылки на различные доступные модули.Имеет ли это смысл или есть лучший способ?Я знаю, что SharePoint был бы хорошим решением, если бы у нас были ресурсы для покупки и настройки SharePoint, но мы этого не делаем.

Ответы [ 3 ]

1 голос
/ 10 сентября 2010

Я думал о создании одного пула приложений в IIS для использования со всеми модулями

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

Я не использовал DonNetNuke, я знаю однукомпания, которая использует мульти-Tenancey модули, которые она имеет.Если система интенсивно использует рабочие процессы, возможно, вы захотите взглянуть на системы рабочих процессов - K2 BlackPearl достаточно хорошо зарекомендовал себя на рынке Microsoft под влиянием.Если вы еще этого не обнаружили (и не собираетесь использовать что-то вроде DNN), то библиотеки Microsoft Enterprise обязательны (см .: MS Patterns & Practices и CodePlex ).

Другие вопросы, которые следует учитывать:

  • Вы хотите иметь хорошую структуру, которая обрабатывает все (действительно) общие вещи (ведение журнала и т. Д.).
  • Мудро держать разные отделы в разных местах;проект для каждого из них плюс проект для портала будет моим подходом.Framework снова станет отдельным.
  • Смоделируйте данные - даже если они находятся на доске.Понимание данных (что передается, что нет, откуда они берутся и кто их использует) очень важно.
  • При рассмотрении повторного использования: не забудьте применить его на нужном уровне.То, что вы пишете конкретный пользовательский интерфейс, не означает, что для него нужно записать конкретный BL и / или DAL.
  • Используйте абстракцию и внедрение зависимостей, чтобы разделить слои (особенно BL и DAL).
  • Используйте принцип разделения интерфейсов , чтобы разделить части системы по вертикали.
1 голос
/ 11 сентября 2010

«Я знаю, что SharePoint был бы хорошим решение, если бы у нас были ресурсы купить и настроить SharePoint, но мы не. "

Если вы имеете в виду Sharepoint services , в зависимости от версии, которая вам нужна, и от того, что у вас уже есть, покупка может быть не включена. Также проверьте DotNetNuke, как упомянуто @balexandre.

Выше было сказано, что если вы идете по специальному маршруту, я бы больше сосредоточился на повторном использовании библиотеки, чем на аспектах развертывания, чтобы разделить ядро. Наличие основного сайта + двух папок приложения - это хорошо, но не стоит вовлекать вас в вызовы между приложениями, если для ваших сценариев подойдут более простые вызовы библиотеки.

Не обращайтесь к основной базе данных напрямую из 2 приложений. Используйте операции бизнес-уровня для доступа к данным и определения очень четкой границы / с очень простыми операциями. Граница очень важна, если вы попытаетесь смоделировать 3 проекта на низком уровне одновременно, это будет означать только ненужные сложности / как во время анализа, так и в полученном продукте. Размышляя о трех проектах одновременно, держите их на высоком уровне, как это должно быть в операциях на границе. Именно так оно и будет работать, если позже вы получите другие приложения / проекты - в противном случае вы окажетесь с очень трудными решениями с более чем 5 продуктами информации и очень большой головной болью.

0 голосов
/ 09 сентября 2010

Я бы сказал, простая вещь, чтобы у вас не было головной боли при создании чего-то существующего ...

для портала и модулей ASP.NET использования DotNetNuke

это с открытым исходным кодом, так что у вас уже есть весь код ... строить на нем!

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...