Библиотека за потребителски контрол на ASP.NET за многократна употреба: доставчик на виртуален път или копие на ascx/aspx?

Имам уеб приложение ASP.Net, което искам да използвам като многократна потребителска контролна библиотека в други уеб приложения.

Едно решение за този проблем е да използвате това, което Скот Гътри е описал тук:

http://weblogs.asp.net/scottgu/archive/2005/08/28/423888.aspx

това е да копирате ascx/aspx файлове (без техния код) в уеб приложенията, които използват контролната библиотека.

Всъщност виждам друго решение: да вградите ascx/aspx в потребителската контролна библиотека и след това да използвате персонализиран доставчик на виртуален път, за да ги получите.

Някой знае ли кое решение е най-доброто?

От гледна точка на внедряване доставчикът на виртуален път изглежда по-добър. Решението „ascx/aspx copy“ обаче е по-лесно за изпълнение (няма нужда да създавате потребителски доставчик на виртуален път).


asp.net user-controls virtualpathprovider
person Thierry    schedule 22.12.2009    source източник

Отговори (3)


arrow_upward
1
arrow_downward

Наистина не ми харесва решението на Скот. Вярвам, че е грозно и създава допълнителни разходи, които не са необходими. Аз също съм виждал нещо подобно в действие и просто не ми се получи.

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

Доставчикът на виртуален път обаче има няколко проблема:

  • Ако вашият ascx файл има някакви сървърни тагове (в javascript или на друго място по този въпрос), които причиняват проблем, ще получите грешка по време на изпълнение, която не е толкова полезна.
  • Трябва да създавате отново приложението си всеки път, когато правите промяна в маркировката на ascx или в Javascript, който съществува в самия файл, за да видите резултатите. Това може да бъде истинска болка, ако се опитвате да промените дизайна на съществуващ контрол.

Използвах решението, както е описано в тази статия, и то работи много добре:

http://www.codeproject.com/KB/user-controls/EmbeddedUserControl.aspx

Надявам се това да помогне...

person tolism7    schedule 22.12.2009

arrow_upward
1
arrow_downward

Попаднах в същата ситуация преди няколко седмици и не можах да накарам решението на Скот да работи. Вместо това използвах персонализирани сървърни контроли и ги поставих в тяхната собствена библиотека с класове.

person Mike Cole    schedule 22.12.2009

arrow_upward
1
arrow_downward

Потребителите, изпълняващи преки пътища в пакетни файлове, могат да получат предупреждения за сигурност. Бих предпочел да не създавам навика на потребителите да пренебрегват предупрежденията за сигурност. Освен това някои потребители никога няма да стартират тези групови файлове и т.н., и т.н.
person Gabriel McAdams    schedule 22.12.2009