2010-10-10 4 views
13

Я создаю многопользовательское приложение ASP.NET. Учитывая, что каждый арендатор может динамически настраивать свое приложение (которое может включать динамические пользовательские сборки, загружаемые в память), мне нужен способ изолировать каждого арендатора.Изоляция в многопользовательском ASP.NET приложении

Я бы предпочел не создавать новое веб-приложение для каждого арендатора по причинам технического обслуживания.

Я рассматривал возможность использования AppDomainManager для создания AppDomain для каждого приложения, но, похоже, это не предназначено для использования в приложениях ASP .NET.

У кого-нибудь есть предложения по этому вопросу?

Спасибо.

ответ

5

Я думаю, вопрос: если вы не создаете веб-приложение, то какой тип изоляции действительно вам подходит?

Если вам действительно нужна гарантия уровня ОС, что сборки не будут работать друг с другом, я бы предоставил каждому свое веб-приложение. Это особенно актуально, если вы разрешаете людям загружать сторонние сборки и, что особенно важно, если эти сторонние сборки могут найти способы создания неуправляемого кода.

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

+0

Я второй, ключевая фраза - «пользовательские сборки». –

+0

Хорошо, я определенно согласен с этим, но у меня есть несколько проблем. Один - все приложения должны иметь один и тот же корневой URL ... это возможно? Два - создание и удаление должно быть автоматическим ... следует ли использовать WMI для этого? Я не знаю, как я к этому отношусь ... И сколько webapps поддерживает IIs? Будет ли это масштабирование в облаке аппаратных средств, поскольку ограничение было бы os? Три - мы хотим, чтобы это решение было совместимым с Azure (но не специфичным для Azure), так как я могу управлять его для Azure? – Jeff

+0

Кроме того, как вы порекомендуете обращаться с общими ресурсами (страницами)? VirtualPathProvider, который извлекает страницу из общих DLL? – Jeff

1

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

Один ... Таким образом, URL-адрес корня останется прежним. Два ... Создание VDir или экземпляр приложения. Какой из них должен быть динамичным? Три ... У меня нет опыта.

Если бы мне пришлось делиться страницами [на основе приложений, размещенных в разных VDir], я бы пошел на создание нового VDir для всех моих общих страниц. И используйте специальный код для отображения данных, связанных с приложением.

+0

Как бы я хотел динамически создавать приложения, это вопрос? – Jeff

+0

Если вы используете IIS 7, вы можете использовать делегирование конфигурации виртуальных каталогов IIS для своих конечных пользователей, чтобы они могли настраивать свои приложения. –

+0

ИЛИ, вы можете использовать SharePoint или DotNetNuke. Если я правильно понял ваш вопрос, вы можете использовать SharePoint для создания определения сайта и использовать его как шаблон для своих сайтов. –

1

Я написал многопользовательское веб-приложение в MVC2. Добавление/удаление учетной записи так же сложно, как добавление/удаление строки в таблице, поскольку я выбрал подход к общей базе данных, общей схеме.

Это очень хорошая статья о разработке базы данных многопользовательских из MSDN: Multi-Tenant Data Architecture

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

  • www.yourdomain.com/Account1/...
  • www.yourdomain.com/Account2/...
  • www.yourdomain.com/Account3/...

и у меня есть собственный MvcHandler для поиска учетной записи для каждого запроса:

public class AccountMvcHandler : MvcHandler 
{ 
    public AccountModel Account { get; set; } 

    public AccountMvcHandler(RequestContext requestContext) 
     : base(requestContext) 
    { 
    } 

    protected override IAsyncResult BeginProcessRequest(HttpContextBase httpContext, AsyncCallback callback, object state) 
    { 
     string accountName = this.RequestContext.RouteData.GetRequiredString("account"); 
     Account = ServiceFactory.GetService<IAccountService>().GetAccount(accountName); 

     // URL doesn't contain valid account name - redirect to login page with Account Name textbox 
     if (Account == null) 
      httpContext.Response.Redirect(FormsAuthentication.LoginUrl); 

     return base.BeginProcessRequest(httpContext, callback, state); 
    } 
} 

Как был сказан Андреасом Paulsson ключевой фразой является «пользовательскими сборками». Зачем вам нужны «настраиваемые сборки» для настройки?Вы используете CodeEmit? Будут ли пользователи загружать их? Я бы предпочел использовать Windows Workflow Foundation для любой клиентской бизнес-логики.

+0

На самом деле у меня есть настроенные для арендатора маршруты MVC, которые отлично работают. Целью пользовательских сборок является то, что арендаторы должны иметь возможность настраивать свой «экземпляр» с помощью настраиваемых страниц и задержек кода. Выделение любого специального кода для этой цели является ключевым. – Jeff

+0

Чтобы уточнить, да, пользователи будут загружать пользовательские сборки, которые будут скомпилированы и запущены в домене приложения. Проблема в том, что эти сборки нуждаются в некоторой форме изоляции, чтобы не иметь доступа к данным от других арендаторов. У меня уже есть код, который мешает пользовательским сборкам делать вызовы БД, но меня беспокоят статические контексты, такие как состояние приложения или статические свойства/методы/поля. – Jeff

+0

Я рассматривал динамическое создание доменов приложений для этих пользовательских сборок, но я бы предпочел что-то интегрированное, поскольку asp .net уже управляет доменами приложений для меня. Кроме того, я не уверен, как получить свой пользовательский домен приложения в жизненном цикле asp .net request (возможность выдавать страницы aspx, сделанные aspx) – Jeff

 Смежные вопросы

  • Нет связанных вопросов^_^