Здраствуйте!

Долго читал мсдн по теме архитектуры ASP.NET. Написано так: при запросе клиента к серверу, сервер подружает (или компилирует если надо) сборку указанную в заголовке запрошенного aspx. Потом, загрузив сборку, он создает объект Page, инициализирует все его компоненты, ну по ходу дела наступают события типа Load, Init, пользовательские события и т.д. Все это выполняется как надо и потом в самом конце перед выгрузкой, этот объект Page создает html страницу вызывая специальные методы (методы создающие html в Respons'e) своих компонентов (визуальных компонентов).

Ну так вот, спрашивается тогда, а зачем в самом файле aspx описывать элементы управления? То есть писать там <asp:Label..... и так далее. Если все эти элементы управления прописаны в классе страницы и код для их отображения тоже производит DLL'ка страницы???

Спасибо.

Здравствуйте, Артем1, Вы писали:

А>2 предположения:

А>1. часть dll-ки с контролами формируется путем разбора aspx-страницы, на которой эти контролы и объявлены, а это дает возможность визуального дизайна

Ну тут во-первых длл если лежит на сервере, то это уже полноценная сборка, то есть в самом классе страницы УЖЕ определены все контролы, в 2005 студии партиал классы например работают так: программер пишет свой кусок партиал класса в кодебехаинд классе, то есть он пишет чисто методы класса, обработчики событий, ну и может еще свою функциональность добавить. Потом при паблише например, когда студия компилирует класс в сборку, сама студия еще добавляет в этот партиал класс свой код, ну там всякие объявления контролов, кой какие методы и т.д. Это еще не все, потом в этот класс добавляется еще кой какой служебный код и класс переименовывается в имякласса_aspx, и потом он уже компилится в сборку. Короче механизм такой.

А>2. при определенных настройках можно подправить код aspx прямо на рабочем сервере, и dll-ка сама перекомпилится. в dll-ке напрямую так не поправишь

Ну это понятно, вообще по теме вопроса есть предположение такое: эти объявления контролов в aspx файле нужны для того, чтобы при формировании страницы, которая отсылается клиенту, html код всех контролов находился в нужных местах на странице. Или я не прав?

А вот такой есть еще вопрос заодно по архитектуре.

Когда веб приложение запускается на сервере, начинаются отсылки страниц клиентам и так далее. Но само приложение насколько я понимаю на сервере существует пока последний клиент не закончит с ним работать. Поэтому вопрос такой, можно в веб приложении замутить такую функциональность, чтобы допустим как бы в отдельном потоке что нибудь выполнялось вне зависимости от запросов/ответов пользователей. И например еще круче, сделать так чтобы допустим веб приложение на сервере что то там делало и при определенных обстоятельствах посылало клиенту определенному (или всем клиентам) какую нибудь страницу (то есть посылало её не зависимо от того запрашивал клиент что нибудь или нет)???

Или такого с веб приложениями замутить не получиться?

Здравствуйте, Артем1, Вы писали:


А>Ну в web-приложении такое действительно сделать вряд-ли возможно. Особенно отсылку клиентам принудительную. Но как вариант можно в Application положить какой-нить поток, который будет себе работу работать потихоньку и туда-же выкладывать переодически инфу о состоянии процесса, а при request-ах клиента проверять эту инфу и выдавать соотв-ее сообщение либо редиректить клиента на нужную страницу. А что это за задача такая, если не секрет?

Ну как таковой задачи сейчас нет, но допустим можно таким образом (с потоком в Application) сделать например такую штуку:

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

Вот так например =), ну естественно в таком случае у Application на каждого клиента должен быть установлен таймаут несколько часов.

Здравствуйте, Артем1, Вы писали:

А>Только там не таймаут огромный выставлялся, а страничка с отображением хода процесса рефрешилась автоматом раз в секунд 10 — и сессия держится, и процесс видно.

А чем плохо в такой ситуации ставить очень большой таймаут? Могут быть проблемы с производительностью или типа того?

Здравствуйте, Mike Chaliy, Вы писали:


MC>Только в клас ничего не добовляеться. Создаеться наследник от него. И он уже имеет название имякласса_aspx.


The inheritance model for code-behind pages is slightly more complex than that for single-file pages. The model is this:

The code-behind file contains a partial class that inherits from a base page class. The base page class can be the Page class, or it can be another class that derives from Page.

The .aspx file contains an Inherits attribute in the @ Page directive that points to the code-behind partial class.

When the page is compiled, ASP.NET generates a partial class based on the .aspx file; this class is a partial class of the code-behind class file. The generated partial class file contains declarations for the page's controls. This partial class enables your code-behind file to be used as part of a complete class without requiring you to declare the controls explicitly.

Finally, ASP.NET generates another class that inherits from the class generated in Step 3. This second generated class contains the code required to build the page. The second generated class and the code-behind class are compiled into an assembly that runs to render output to the browser.

Из мсдн ms-help://MS.MSDNQTR.v80.en/MS.MSDN.v80/MS.VisualStudio.v80.en/dv_aspnetcon/html/01e87387-33f4-45b5-91ec-6c540afe7ee0.htm

MC>Они не прописаны в коде. Точнее они станояться прописаны на момент паблишинга. На момент паблишинга (послденего паблишенга, если вы настроили так штобы можно было редактить аспх файлы, то инфрастуктура асп.нет всерано пропаблишет этот сайт, просто для вас этого будет незаметно), уже не существует аспх странички. Есть пустой файл, он нужен для ИИС. Иначе исс не будет шарить што такой файл вообще сущетсвует. А располжение контролов на этот момент задеться позицией в колекции контролов.

Как понять существует пустой файл необходимый для IIS? А откуда IIS вообще может узнать какую дллку грузить для этого пустого файла? Как минимум должен быть заголовок в этом файле, где прописано имя дллки. Или уж на крайний случай имя дллки должно совпадать с именем запрошенного aspx. По логике так.
А во вторых как этот файл может быть пустым? А хотя бы css классы для каждого контрола где тогда находятся? Тоже в дллке что ли? Так тогда получается что у каждого контрола должно быть миллион дополнительных свойств соответствующих всем аттрибутам типа position: absolute, всякие колоры, и т.д. Или я опять туплю? =)

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Mike Chaliy, Вы писали:


MC>>Только в клас ничего не добовляеться. Создаеться наследник от него. И он уже имеет название имякласса_aspx.



MC>>Они не прописаны в коде. Точнее они станояться прописаны на момент паблишинга. На момент паблишинга (послденего паблишенга, если вы настроили так штобы можно было редактить аспх файлы, то инфрастуктура асп.нет всерано пропаблишет этот сайт, просто для вас этого будет незаметно), уже не существует аспх странички. Есть пустой файл, он нужен для ИИС. Иначе исс не будет шарить што такой файл вообще сущетсвует. А располжение контролов на этот момент задеться позицией в колекции контролов.

А>Как понять существует пустой файл необходимый для IIS? А откуда IIS вообще может узнать какую дллку грузить для этого пустого файла? Как минимум должен быть заголовок в этом файле, где прописано имя дллки. Или уж на крайний случай имя дллки должно совпадать с именем запрошенного aspx. По логике так.
А>А во вторых как этот файл может быть пустым? А хотя бы css классы для каждого контрола где тогда находятся? Тоже в дллке что ли? Так тогда получается что у каждого контрола должно быть миллион дополнительных свойств соответствующих всем аттрибутам типа position: absolute, всякие колоры, и т.д. Или я опять туплю? =)


Вообщем:

You can precompile a Web site using the ASP.NET compiler tool (ASPNET_Compiler.exe). The tool that provides the following precompilation options:

In-place compilation This option performs the same compilation that occurs during dynamic compilation. Use this option to compile a Web site that has already been deployed to a production server.

Non-updateable full precompilation Use this to compile an application and then copy the compiled output to the production server. All application code, markup, and UI code is compiled into assemblies. Placeholder files such as .aspx pages still exist so that you can perform file-specific tasks such as configure permissions, but the files contain no updateable code. In order to update any page or any code you must precompile the Web site again and deploy it again.

Updateable precompilation This is similar to non-updateable full precompilation, except that UI elements such as .aspx pages and .ascx controls retain all their markup, UI code, and inline code, if any. You can update code in the file after it has been deployed; ASP.NET will detect changes to the file and recompile it. Note that code in a code-behind file (.vb or .cs file) built into assemblies during precompilation, and you therefore cannot change it without going through the precompilation and deployment steps again.

Короче первый вариант деплоймента: In-place compilation — просто исходники проекта выкладываются на хостинг (без всяких компиляций) и там после первого запроса клиента они динамически компилятся. Преимущество такого подхода в том что можно прямо на серваке редактировать файлы кода, недостаток в том что при внесении изменений, проект будет пересобран и поэтому клиенту придется ждать пока закончится компиляция прежде чем он получит страницу (только по моему эти задержки не очень и существенны :???: )


Воторой вариант: Короче фишка в том, что есть несколько вариантов деплоймента, один из них Non-updateable full precompilation, при нем весь код страницы помещается в одну сборку длл. Работает это так: сначала апснетом берется кусок партиал класса который написал разработчик, потом к нему приписывается автоматически созданный аспнетом второй кусок этого же партиал класса (в нем объявления контролов, метод InitializeComponents) и в конце к этому классу прибавляется функциональность для вывода маркупа для каждого контрола в соответствии с aspx, потом этот класс переименовывается в имякласса_aspx, компилится и кладется в bin. Преимущества — все работает очень быстро, весь код защищен (условно конечно, если только кулъхацкеръ не имеет пользоваться чем нибудь типа ILDASM). Недостатки — чтобы что то поменять, надо компилить все поновой и выкладывать на сервер, так же если нет исходников то поменять ничего не получится.

И третий вариант деплоймента: Похож на второй, только сборки длл содержат код маркупа (markup) только для контролов, а весь остальной маркуп (где какой контрол находится на странице, внутри каких тегов и т.д.) находится в aspx. Преимущество в том, что можно поменять aspx прямо на сервере и например контрол из одного места страницы переместить в другое. Недостатки, хм, ну может быть то, что кульхацкер сможет просмотреть aspx и что то там испортить.