Приложение за уеб формуляри на ASP.Net с проблем с подлежаща на добавяне архитектура

Беше ми казано да направя plugin уеб приложение. с уеб формуляри. Идеята е да имате едно базово уеб приложение с хост на плъгини, което ще зарежда всички плъгини и свързани с тях уеб страници.

Като пример, имам моето MyHostApplication с основна страница и файл default.aspx. Когато бъде компилиран, основно проектът ще има файловете Site.Master и Default.aspx в главната директория и MyHostApplication.dll в " bin/" реж. Всички добавки ще бъдат да кажем в директория „plugins/“. След това създавам плъгин за калкулатор като нов проект с неговата уеб страница Calc.aspx в тази директория и сборник Calculator.dll в директорията „bin/“ ... или с web.config може да го преместя някъде. Мога да заредя асемблирането в хост приложението с LoadAssembly и да получа главния клас (който имам като базов клас и всички базови класове на плъгини наследяват този клас) и да получа някаква информация от него в свойствата, като име, версия, позиция в меню и др.

Сега проблемът - когато навигирам до /plugins/Calculator.aspx (да кажем от менюто Инструменти, което аз съм създал хостът на приставката), той зарежда сборката си и не знае за основния хост приложение. Но трябва да се премине през основното приложение. Също така би трябвало да е най-добре, ако по някакъв начин мога да използвам основната страница на основното приложение със страницата на приставката.

Може ли някой да ми даде помощ тук? Благодаря предварително.


plugins architecture asp.net webforms
person Vasil Popov    schedule 16.09.2010    source източник

Отговори (3)


arrow_upward
0
arrow_downward

Не е директен отговор на въпроса ви, но изследвали ли сте MEF

Тя се основава на същите принципи и може да ви помогне да получите преднина в това, което се опитвате да постигнете.

person Jagmag    schedule 16.09.2010
comment
Благодаря за идеята, пробвах с MEF, но не ми стана ясно кога включвам страница или много страници като част от плъгина. Дойдох с решение, използвайки платформата .Net MVC2, което поставих в отговор на въпроса. - person Vasil Popov; 20.09.2010

arrow_upward
0
arrow_downward

thus could potentially run faster than the complex, hand-tweaked solutions posted in this thread. Това зависи от размера на списъците. Проверихте ли вашата алгоритмична сложност? Не съм, но ако е N^2, тогава може да се наложи да увеличите мощността на обработка експоненциално, за да поддържате темпото. Предполагам, че законът на Мур би ви покрил засега, но все пак :) За сценарии от реалния свят обаче, разбира се, ще има горна граница за размера на тези списъци
person Adrian K    schedule 17.09.2010
comment
Всички случаи съм правил на хартия преди, така че ми е ясно какво трябва да се направи. Проблемът за мен беше, с идеята за уеб формуляри, когато поискаме някои от уеб страниците, които са били копирани с плъгин, как ще идентифицира основното приложение, тъй като ще изпълни своето сглобяване, още ... проверка на лицензите и дали регистрираният потребителят може да използва този плъгин. Също така използването на основната страница е трудно. - person Vasil Popov; 20.09.2010

arrow_upward
0
arrow_downward

Благодаря за отговорите! Най-накрая получих това, което търсих :) ... Видях урок само за моя случай, който е решен с MVC v.2, като отговаря идеално на моята идея.

Може да бъде намерен тук. Той е много елементарен, но решава проблема със страниците на приставката и използването на основната страница, също така можем да управляваме много лесно лицензите за приставката и версиите. Другото нещо е, че харесвам jQuery, който се използва тясно с него, така че идеята работи за мен :)

person Vasil Popov    schedule 20.09.2010