Asp построение приложений asp


Содержание

Построение ASP.NET приложений

Некоторые фреймворки настаивают на создании и управлении жизненным циклом написанных нами классов. Самый популярный фреймворк – ASP.NET (Web Forms, в противоположность MVC).

Некоторые другие фреймворки, разделяющие эту особенность, – это Microsoft Management Console (MMC), управляемый SDK, и такая недавняя разработка, как PowerShell.

Наиболее очевидным симптомом таких фреймворков является то, что, чтобы им подойти, наши классы должны обладать конструктором по умолчанию. В ASP.NET, например, любой реализуемый нами класс Page должен обладать непараметризованным конструктором. Мы не можем использовать Constructor Injection в рамках этих фреймворков, поэтому давайте рассмотрим наши возможности.

ASP.NET композиция

Паттерн Constructor Injection был бы предпочтительным, поскольку он позволял бы удостовериться, что наши классы Page будут правильно инициализироваться совместно с их зависимостями. Так как это невозможно, мы должны выбирать между следующими альтернативными вариантами:

  • Перемещать и дублировать наши Composition Root’ы в пределах каждого класса Page .
  • Использовать Service Locator для того, чтобы преобразовать все зависимости в пределах каждого класса Page .

Тем не менее, не забывайте о том, что Service Locator – это анти-паттерн, поэтому такой вариант не желателен. Наилучшая альтернатива – пойти на компромисс в вопросе расположения нашего Composition Root.

В идеале, мы бы предпочли сценарий, продемонстрированный на рисунке 7-13, при котором мы имеем всего один Composition Root для приложения, но в ASP.NET это невозможно, поскольку мы не можем компоновать экземпляры Page извне. Другими словами, фреймворк Web Forms вынуждает нас компоновать приложение в пределах каждого Page .

Рисунок 7-13: В идеальном мире нам хотелось бы уметь компоновать объекты Page из Composition Root приложения. При получении запроса мы должны уметь использовать определенную конфигурацию зависимостей для того, чтобы скомпоновать соответствующий объект Page . Тем не менее, это невозможно, поскольку ASP.NET управляет жизненным циклом объектов Page от нашего имени.

До настоящего времени я говорил только об объектах Page , но ASP.NET требует, чтобы большинство объектов обладали конструкторами по умолчанию в случае, если мы хотим использовать фреймворк. Еще одним примером является Object Data Sources. Обсуждение, имеющее место в данном разделе, в равной степени хорошо применяется ко всем остальным типам, которые должны обладать конструктором по умолчанию.

Чтобы обратиться к этой проблеме, мы должны подвергнуть риску наши идеалы, но компромисс в вопросе расположения наших Composition Root’ов кажется мне более безопасным, чем позволить Service Locator вступить в игру.

По существу мы преобразуем каждый Page в Composition Root, как это продемонстрировано на рисунке 7-14. Принцип единичной ответственности напоминает нам о том, что каждый класс должен иметь только одну ответственность; теперь, когда мы используем Page для того, чтобы скомпоновать все необходимые зависимости, мы должны делегировать ответственность за реализацию реализатору (implementer). Такой подход эффективно преобразует Page в humble-объект («скромный» объект), раскрывая другие члены, такие, как обработчики события нажатия кнопки только для того, чтобы делегировать полномочия реализатору преобразованного Page .

Рисунок 7-14: В ASP.NET мы можем использовать точку входа в приложение (global.asax) для того, чтобы конфигурировать зависимости, но потом до того, как мы сможем продолжить композицию, нам придется ждать, пока фреймворк не создаст новый объект Page . В пределах каждого Page мы можем использовать сконфигурированные зависимости для того, чтобы скомпоновать реализатор, который реализует все поведение класса Page .

Различие между вариантом перемещения Composition Root в каждый класс и вариантом использования Service Locator – трудно уловимо. Разница заключается в том, что благодаря Service Locator мы можем преобразовывать зависимости каждого класса Page в индивидуальном порядке, и использовать их напрямую в пределах класса Page . Как обычно бывает с Service Locator, он склонен к размытию фокуса класса. Кроме того, довольно заманчиво сохранить контейнер и использовать его для того, чтобы преобразовать остальные зависимости как надо.

Чтобы противодействовать этой тенденции, важно использовать наш контейнер только для преобразования реализатора, а затем – забыть о нем. Это позволяет нам руководствоваться подходящими DI-паттернами (например, Constructor Injection) для остальной части кода приложения.

Несмотря на то, что это только теория, вы расслабитесь, услышав, что это легко реализовать. Лучше всего это иллюстрируется на примере.

Пример: подключение CampaignPresenter

Шаблонное приложение Commerce, которое вы знаете и любите, поддерживает такие возможности, как скидки на товары и список рекомендуемых товаров, но до настоящего момента вы не обеспечивали потребителей приложением, которое управляло бы этими аспектами. В данном примере мы рассмотрим, как компоновать ASP.NET приложение (продемонстрировано на рисунке 7-15), которое позволяет потребителю обновлять данные об акциях для товара.

Рисунок 7-15: Приложение CampaignManagement позволяет промышленным потребителям редактировать данные об акциях (Featured (Рекомендуемые) и Discount Price (Цена со скидкой)) для товара. Это ASP.NET приложение, построенное с элементом управления GridView , привязанным к элементу управления ObjectDataSource .

Говоря простыми словами, это приложение состоит из единственного элемента управления, привязанного к ObjectDataSource . Источник данных – это класс конкретного приложения, который делегирует свое поведение доменной модели и, в конечном счете, передает его в библиотеку доступа к данным, которая хранит данные в базе данных SQL Server.

Вы все еще можете использовать global.asax для конфигурирования зависимостей, но вы должны отложить компоновку приложения до тех пор, пока не будут созданы Page и его ObjectDataSource . Конфигурирование зависимостей схоже с предыдущими примерами.

Конфигурирование зависимостей в ASP.NET

В ASP.NET точкой входа в приложение является файл global.asax, и, несмотря на то, что вы ничего не можете компоновать в этой точке, вы можете создать свой mise en place, подготавливая все для запуска приложения:

Единственное, что вы здесь делаете, – создаете ваш контейнер и сохраняете его в Application Context, поэтому вы можете использовать его, когда вам это нужно. Это позволяет вам совместно использовать контейнер в рамках отдельных веб-запросов, которые являются существенными, если вам нужно сохранить некоторые зависимости на время жизненного цикла процесса (более подробно о жизненных циклах мы поговорим в главе 8).

Как и во всех остальных примерах данной главы, я использую Poor Man’s DI для того, чтобы продемонстрировать основные рассматриваемые принципы. CampaignContainer – это пользовательский класс, созданный специально для этого примера, но вы можете легко заменить его выбранным вами DI-контейнером.

Большинство различных Page и объектов источников данных могут совместно использовать один и тот же контейнер посредством обращения к Application Context. Тем не менее, этот подход несет за собой опасность неправильного использования его в качестве Service Locator, поскольку любой класс может потенциально получить доступ к Application Context. Таким образом, важно делегировать реализацию классам, которые не могут получить доступ к Application Context. На практике это означает делегирование полномочий классам, реализованным в других отдельных библиотеках, которые не ссылаются на ASP.NET.

Мы можем также продолжить свой путь слегка дисциплинированно, сдерживая себя от обращения к Application Context, за исключением реализации Composition Root. Это может хорошо подходить в тех случаях, когда все разработчики имеют опыт в написании слабо связанного кода; но если мы думаем, что некоторые члены команды могут не до конца понимать рассматриваемую проблему, мы можем удачно защитить код посредством использования отдельных библиотек. Раздел 6.5 описывает, как это сделать.

В текущем примере вы будете делегировать всю реализацию отдельной библиотеке логики отображения для того, чтобы убедиться, что никакие классы не обращаются напрямую к Application Context. Вы не позволяете библиотеке ссылаться на какую-либо сборку ASP.NET (например, System.Web).

Рисунок 7-16 демонстрирует частичное представление архитектуры приложения. Основной момент – это тот факт, что вы используете классы центральной части приложения ( Default Page и CampaignDataSource ) в качестве Composition Root’ов, которые преобразуют классы уровня «Логика представления» совместно с их зависимостями.

Рисунок 7-16: Центральная часть приложения CampaignManagement – это единственная составляющая приложения, ссылающаяся на ASP.NET. Класс CampaignDataSource имеет конструктор по умолчанию, но действует как Composition Root или humble-объект, который делегирует все вызовы метода CampaignPresenter . Обычно стрелки обозначают указатели, а центральная часть приложения ссылается на все остальные модули приложения, поскольку она соединяет их вместе. Как модуль логики представления, так и модуль доступа к данным ссылаются на библиотеку доменной модели. Не все рассматриваемые классы продемонстрированы на этом рисунке.

Вооруженные знанием диаграммы зависимостей приложения, мы теперь можем реализовать Composition Root для кадра, продемонстрированного на рисунке 7-15.

Компоновка ObjectDataSource

Default Page , продемонстрированный на рисунке 7-15, состоит из элемента управления GridView и связанного с ним элемента управления ObjectDataSource . Как и в случае с классами Page , класс, используемый для ObjectDataSource также должен обладать конструктором по умолчанию. Для достижения этой цели вы специально создаете класс, продемонстрированный в следующем листинге.

Листинг 7-12: Компоновка Presenter в качестве источника данных

Строка 9: Формирует Presenter

Строка 13, 17: Делегирует полномочия Presenter

Класс CampaignDataSource имеет конструктор по умолчанию, поскольку того требует ASP.NET. Близкий по духу принципу Fail Fast (принцип быстрого отказа), он незамедлительно пытается извлечь контейнер из Application Context и преобразовать экземпляр CampaignPresenter , который будет выступать в роли реальной реализации.

Все члены класса CampaignDataSource делегируют вызов преобразованному предъявителю, таким образом, действуя как humble-объект.

Для приверженцев паттернов проектирования класс CampaignDataSource очень похож либо на Decorator, либо на Adapter. Он не реализует строго типизированный интерфейс, но обертывает соответствующую реализацию в класс, который соответствует требованиям, предъявляемых ASP.NET.

Вам может быть интересно, что мы приобретаем благодаря этому дополнительному уровню преобразования. Если вы привыкли к разработке через тестирование, то это должно быть вам понятно: HttpContext.Current недоступен во время модульного тестирования, поэтому вы не можете выполнить модульное тестирование CampaignDataSource . Это важная причина того, почему вы должны сохранять его humble-объектом.

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

Компоновка Presenter

Я не буду знакомить вас с подробной информацией о CampaignPresenter , но стоит рассмотреть сигнатуру его конструктора, поскольку он использует Constructor Injection:

Зависимостями CampaignPresenter являются абстрактный класс CampaignRepository и интерфейс IPresentationMapper . Как раз то, что делают эти абстракции, менее важно, чем то, как вы их компонуете. Это является задачей CampaignContainer из следующего листинга. Вы можете вспомнить, что вы конфигурировали его в global.asax и регистрировали в Application Context.

Листинг 7-13: Преобразование CampaignPresenter

Строка 6-7: Создает репозиторий

Строка 8-9: Создает преобразователь

Строка 10: Формирует Presenter

Ответственность метода ResolvePresenter – скомпоновать экземпляр CampaignPresenter . Из конструктора вы знаете, что для него нужен CampaignRepository , поэтому вы преобразовываете его в экземпляр SqlCampaignRepository . Другой зависимостью является IPresentationMapper , и вы преобразуете ее в конкретный класс PresentationMapper .

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

Использование механизма внедрения зависимостей в рамках ASP.NET невозможно. Главным недостатком использования каждого Page и источника данных объекта в виде объединенного Composition Root и humble-объекта является то, что для этого необходимо дублирование большинства членов класса.

Обратили ли вы внимание на то, как каждый член CampaignDataSource делегирует свою реализацию схожему по названию методу CampaignPresenter ? Вам придется повторять эту идиому кода на протяжении всего ASP.NET приложения. Для каждого обработчика события нажатия кнопки вам необходимо определить и поддерживать в работоспособном состоянии связанный метод класса Presenter и тому подобное.

Как мы уже обсуждали в главе 3, я приравниваю понятие Composition Root к такому понятию Бережливой разработки программного обеспечения (Lean Software Development), как последний ответственный момент. В рамках таких фреймворков, как ASP.NET MVC и WCF, мы можем отложить композицию приложения вплоть до точки входа в приложение, но в ASP.NET так не делается. Не важно, как упорно мы стараемся, мы можем отложить только принятие решений о композиции объектов, пока не столкнемся с требованием о необходимости наличия конструктора по умолчанию.

Потом это становится «самым возможным местом», в котором мы можем компоновать объекты. Несмотря на то, что мы считаем, что пришли к компромиссу, мы все еще следуем всеобщему духу Composition Root. Мы компонуем иерархии объектов настолько близко к верхним уровням приложения, насколько это возможно, и разрешаем корректные DI-паттерны как здесь, так и на более низких по иерархии уровнях.

Вопрос по asp.net &#8211 Создание приложения ASP.NET — лучшие практики

Мы создаем приложение ASP.NET и хотели бы следовать рекомендациям. Некоторые из лучших практик:

Код на стороне сервера:

Используйте блоки поймать, чтобы поймать и регистрировать ошибки низкого уровня тоже.Используйте объекты Cache для заполнения выпадающих списков и т. Д., Где мы выигралиНе ожидайте изменений в базовых данных / базе данных.В случае каркаса регистрации ошибок, отправьте оповещения по электронной почте вместе с регистрацией ошибок.

HTML-код: — Не делайт встроенный CSS. — Поместите код JavaScript (если он необходим странице) в конец страницы, если только он не нужен странице для действий во время загрузки.

Теперь перейдем к вопросу: не могли бы вы поделиться этими рекомендациями, если у вас уже есть их полный список?

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

  • Дон»писать код .NET непосредственно в разметке ASPX (если только он не предназначен для привязки данных, то есть Evals). Если у вас есть код позади, это помещает код для страницы в более чем одно место и делает код менее управляемым. Поместите весь код .NET в свой код.
  • SessionPageStatePersister может использоваться вместе с ViewState, чтобы сделать ViewState полезным без увеличения размеров страницы. Перезаписать страницуs PageStatePersister с новым SessionPageStatePersister сохранит все данные ViewState в памяти и будет хранить только зашифрованный ключ на стороне клиента.
  • Создайте BasePage, от которого ваши страницы могут наследовать, чтобы повторно использовать общий код между страницами. Создайте MasterPage для ваших страниц для визуального наследования. Страницы с совершенно разными визуальными стилями должны использовать другую мастер-страницу.
  • Создайте перечисление имен ключей параметров страницы в каждой WebForm, которые передаются через URL, для настройки строго типизированных параметров страницы. Это предотвращает необходимость использования жестко закодированных строк ключей параметров страницы и их возможного неправильного набора, а также позволяет строго типизированный доступ к параметрам с других страниц.
  • Используйте кэш ASP.NET для кеширования часто используемой информации из вашей базы данных. Создайте (или повторно используйте из другого проекта) общий уровень кэширования, который обернет кэш ASP.NET.
  • Оберните объекты ViewState свойствами на своих страницах, чтобы избежать ошибок в написании и т. Д. При обращении к элементам из коллекции ViewState.
  • Старайтесь не помещать большие объекты и графы объектов во ViewState, используйте его в основном для хранения идентификаторов или очень простых объектов DTO.
  • Оберните ASP.NET-сессию с помощью SessionManager, чтобы избежать ошибок разработки в написании и т. Д. При обращении к элементам из Session.
  • Широко используйте значения конфигурации ключ / значение applicationSettings в web.config — оберните Configuration.ApplicationSettings классом, который можно использовать для простого извлечения параметров конфигурации без необходимости запоминать ключи из web.config.
  • Избегайте простоты установки свойств отображения в элементах управления вашего пользовательского интерфейса, вместо этого используйте стили и классы CSS — это сделает ваши стили более управляемыми.
  • Создайте UserControls в своем приложении, чтобы повторно использовать общие функциональные возможности пользовательского интерфейса на своих страницах. Например, если выпадающий список, содержащий коллекцию категорий, будет использоваться во многих местах на сайте — создайте элемент управления CategoryPicker, который будет связывать себя при загрузке страницы.
  • Используйте Свойства на ваших элементах управления UserControls, чтобы настроить такие вещи, как значения по умолчанию, различные отображения между страницами и т. Д. Свойства типа значения можно определить в ваших элементах управления UserControls, а затем задать их в разметке ASP.NET с помощью свойств уровня класса в UserControls.
  • Используйте элементы управления проверкой ASP.NET для выполнения простых проверок или используйте CustomValidator для выполнения сложных проверок.
  • Создайте страницу обработки ошибок, на которую можно перенаправлять, когда на вашем сайте возникает необработанное исключение. Перенаправление может происходить через событие Page_Error на вашей странице, событие Application_Error в вашем Global.asax или в разделе внутри web.config.
  • При работе со страницами, которые используют высокодинамичный дисплей, управляемый данными, используйте сторонний (бесплатный) элемент управления DynamicControlsPlaceholder, чтобы упростить код, необходимый для сохранения состояния динамически добавленных элементов управления между постбэками.

ASP.NET

  • Если вы нене использовать состояние сеанса, нене забудьте выключить его.
  • использование Server.Transfer вместо Response.Redirect если возможно.
  • Установите срок действия в IIS.
  • Используйте GZip для сжатия текстовых файлов.
  • Используйте проверку на стороне сервера и на стороне клиента вместе.
  • Используйте Url Rewriter или Routing, чтобы создать дружественный URL для SEO.

дизайн

  • Напишите каждый класс и его свойства вашего CSS-файла в одной строке. (Чтобы уменьшить размер файла)
  • Используйте CSS Sprites. (Уменьшить запрос)

Asp построение приложений asp

ASP.NET предоставляет службы приложения, доступные через сеть Интернет. С их помощью можно разрешить клиентским приложениям доступ к сведениям о проверке подлинности пользователей, а также о ролях и профиле. Доступ к данным службам могут получать клиентские приложения, написанные на других языках или работающие в других операционных системах. Единственное требование заключается в том, что данные клиенты должны поддерживать взаимодействие по протоколу SOAP 1.1.

В данном пошаговом руководстве описывается настройка и использование служб приложения ASP.NET. Пошаговое руководство состоит из следующих частей:

В первой части показаны способы настройки веб-узла ASP.NET для предоставления служб приложения.

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

В последней части описывается развертывание веб-сайта служб приложения в системе Windows Server 2008 и в службах IIS 7.0.

Для выполнения этого пошагового руководства потребуется следующее.

Visual Studio 2010. Для данного пошагового руководства нельзя использовать Microsoft Visual Web Developer 2005, поскольку будет создано консольное приложение Windows, которое не поддерживается в Visual Web Developer Express.

Установленное на компьютере приложение Microsoft SQL Server или SQL Server Express.

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

Илон Маск рекомендует:  Что такое код imap_header

Для этого пошагового руководства необходимо использовать проект веб-сайта или веб-приложения на базе файловой системы. Сведения о различиях между этими типами проектов см. в разделе Сравнение проектов веб-приложений с проектами веб-сайтов . При выполнении данного пошагового руководства предполагается, что для запуска примеров вместо служб IIS используется сервер разработки Visual Studio Development Server. Дополнительные сведения см. в разделе Веб-серверы в Visual Studio для веб-проектов ASP.NET . Сведения о развертывании приложения в Windows Server 2008 см. далее в разделе этого руководства Развертывание веб-сайта служб приложения в системе Windows Server 2008 .

Создание веб-узла служб приложения

Откройте Visual Studio 2010.

В меню Файл выберите пункт Создать веб-узел .

Откроется диалоговое окно Новый веб-узел .

В разделе Установленные шаблоны Visual Studio выберите Веб-сайт ASP.NET .

В списке Расположение выберите пункт Файловая система .

В текстовом поле Папка введите имя веб-сайта WcfApplicationServices .

Примечание

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

Нажмите кнопку ОК .

Visual Studio создаст новый веб-сайт ASP.NET и откроет страницу Default.aspx.

В меню Вид выберите пункты Другие окна и Окно свойств .

В обозревателе решений щелкните имя веб-сайта.

В окне Свойства присвойте свойству Использовать динамические порты значение False .

Таким образом Visual Studio получает команду на указание фиксированного порта вместо произвольного порта при запуске сервера разработки ASP.NET. Для выполнения данного пошагового руководства необходимо знать фиксированный номер порта, который будет использован при создании клиентских прокси-классов и файлов конфигурации. Дополнительные сведения см. в разделе Пошаговое руководство. Указание порта сервера разработки .

Примечание

Из окна Страницы свойств нет доступа к окну Свойства веб-узла .

В поле Номер порта введите 8080.

Примечание

Можно использовать любой доступный порт. Если используется другой порт, следует отметить номер порта, чтобы впоследствии можно было заменить его на номер 8080.

Сведения о членстве ASP.NET, ролях и профиле хранятся в базе данных. Эта база данных создается автоматически при первом обращении к ней. В следующей процедуре будет написан код, создающий пользователей и роли для веб-сайта. База данных создается автоматически при первом обращении к веб-сайту. Кроме того, в нее добавляются две роли (Managers и Friends).

Создание сведений о пользователях и ролях

Добавьте к веб-сайту файл Global.asax.

Откройте файл Global.asax и замените в нем существующий метод Application_Start на следующий код:

При первом доступе к веб-сайту код создает локальную базу данных Aspnetdb.mdf в папке App_Data и добавляет в нее роли Managers и Friends. Эта база данных используется для хранения сведений об учетных данных, ролях и профиле пользователя.

Откройте страницу Default.aspx и замените разметку на странице следующей разметкой.

Эта разметка создает ссылки на страницу входа, страницу сведений о профиле и страницу нового пользователя. Эти страницы будут добавлены позднее в данном пошаговом руководстве.

В файле Default.aspx с выделенным кодом добавьте следующий код в метод Page_Load :

Этот код определяет, прошел ли текущий пользователь проверку подлинности.

Добавьте страницу с именем Login.aspx.

Добавьте элемент управления Login в файл Login.aspx.

В следующем примере показана разметка для файла Login.aspx.

Добавьте страницу с именем ProfileInfo.aspx и убедитесь в том, что флажок Размещать код в отдельном файле установлен.

Добавьте на страницу ProfileInfo.aspx следующую разметку:

Страница профиля содержит элементы управления Label , используемые для отображения имени и роли пользователя, и элементы управления TextBox , используемые для изменения имени пользователя и его телефонного номера.

В файле с выделенным кодом для страницы ProfileInfo.aspx добавьте следующий код:

Код на данной странице позволяет получать и изменять сведения о профиле пользователя.

Примечание

Проект не будет скомпилирован до тех пор, пока не будут включены свойства профиля для данного веб-узла. Это будет сделано в следующей процедуре.

Добавьте страницу с именем CreateUser.aspx и добавьте в нее следующую разметку.

В файле с выделенным кодом для страницы CreateUser.aspx добавьте следующий код:

На данной странице можно создавать пользователей и назначать для них роли.

На следующем этапе предлагается включить на веб-узле свойства проверки подлинности форм, ролей и профиля. Это можно сделать с помощью параметров в файле «Web.config».

Настройка свойств проверки подлинности, ролей и профиля

Откройте файл Web.config веб-сайта.

В элементе authentication раздела system.web настройте установленную по умолчанию проверку подлинности Windows на использование форм, как показано в следующем примере.

В разделе system.web настройте службу ролей, добавив элемент roleManager , как показано в следующем примере.

В разделе system.web настройте службу профиля с помощью раздела profile и его элемента properties , как показано в следующем примере.

Этот параметр профиля задает три свойства ( FirstName , LastName и PhoneNumber ), которые будут управляться службой профиля ASP.NET. Во время выполнения ASP.NET будет динамически создавать класс типа ProfileCommon , содержащий эти свойства.

В следующем примере показана часть файла Web.config со всеми требуемыми изменениями.

Теперь можно приступать к созданию сведений о пользователе, которые впоследствии будут использованы для входа.

Создание пользователей и назначение сведений о профиле

Выберите в обозревателе решений страницу Default.aspx, а затем нажмите сочетание клавиш CTRL+F5, чтобы запустить эту страницу.

Страница откроется в обозревателе со следующим URL-адресом:

Выберите пункт Новый пользователь .

Отобразится страница «CreateUser.aspx».

Необходимо создать несколько пользователей и назначить для них предварительно определенные роли. Для этого следует ввести учетные данные пользователя и выбрать команду Создать пользователя .

Запишите созданные имена пользователей и пароли. Эти сведения потребуются для того, чтобы назначить или изменить сведения о профиле пользователя.

Например, создайте пользователя с именем joeM и установите переключатель Managers , чтобы сделать пользователя joeM участником роли Managers. Создайте второго пользователя с именем joeNA и установите переключатель Friends . Пользователь joeNA будет участником роли Friends, но не будет участником роли Managers. Роли Friends и Managers созданы кодом, который был добавлен ранее в метод Application_Start файла Global.asax.

После завершения создания пользователя произойдет переадресация на страницу Default.aspx.

На странице «Default.aspx» выберите команду Вход .

Отобразится страница «Login.aspx».

Следует выполнить вход с помощью учетных данных одного из ранее созданных пользователей.

Если вход выполнен успешно, произойдет переадресация на страницу Default.aspx.

Выберите пункт Сведения о профиле .

Отобразится страница «Profile.aspx».

Необходимо ввести или обновить сведения о профиле пользователя, для которого выполнен вход, путем ввода имени, фамилии и номера телефона.

Выберите команду Обновить данные профиля .

Выберите пункт Чтение сведений о профиле .

Отобразится только что введенная информация. Этот шаг позволяет убедиться, что свойства профиля работают.

Вернитесь на страницу Default.aspx.

Выйдите из учетной записи пользователя в роли Managers.

Войдите в систему как пользователь из роли Friends.

Например, войдите в качестве пользователя joeNA.

Введите сведения о профиле для пользователя, вошедшего в систему.

Создание пользователей, ролей и сведений о профиле завершено. Теперь следует открыть доступ к сведениям для клиентских приложений.

Сопоставление и настройка служб приложения

Теперь можно предоставить сведения о созданном пользователе с помощью служб приложения ASP.NET. Прежде чем получить доступ к учетным данным пользователя и сведениям о профиле клиента, необходимо создать файлы сопоставления (SVC), которые указывают на службы приложения. Таким образом можно открыть доступ к службам для любого приложения, запущенного на любой платформе, которое может принимать и получать сообщения в формате SOAP. Также необходимо настроить веб-узел таким образом, чтобы службы приложения предоставлялись в сети.

Создание файлов сопоставления служб приложения

Добавьте файл служб WCF (SVC-файл) на веб-сайт и присвойте ему имя MyAuthenticationSvcWrap.svc.

Откройте файл MyAuthenticationSvcWrap.svc и замените существующую директиву @ ServiceHost следующей директивой, которая создает ссылку на класс System.Web.ApplicationServices AuthenticationService :

В данном примере службы не реализуется пользовательская служба проверки подлинности. Вместо этого вызывается встроенный класс System.Web.ApplicationServices AuthenticationService .

Удалите файлы интерфейса и класса для службы MyAuthenticationSvcWrap в каталоге App_Code (App_Code\MyAuthenticationSvcWrap и App_Code\IMyAuthenticationSvcWrap).

Эти файлы интерфейса и класса были созданы при добавлении SVC-файла в проект. Эти файлы не нужны, поскольку используется служба System.Web.ApplicationServices AuthenticationService , а пользовательская служба не реализуется.

Добавьте еще один файл служб WCF (SVC-файл) на веб-узел и присвойте ему имя MyRoleSvcWrap.svc.

Откройте файл MyRoleSvcWrap.svc и замените его содержимое следующей директивой @ ServiceHost , создающей ссылку на класс System.Web.ApplicationServices RoleService :

В каталоге App_Code удалите файлы интерфейса и класса для службы MyRoleSvcWrap.

Добавьте еще один файл служб WCF (SVC-файл) на веб-узел и присвойте ему имя MyProfileSvcWrap.svc.

Откройте файл MyProfileSvcWrap.svc и замените его содержимое следующей директивой, создающей ссылку на класс System.Web.ApplicationServices ProfileService :

В каталоге App_Code удалите файлы интерфейса и класса для службы MyProfileSvcWrap.

Сохраните и закройте все SVC-файлы

Выполните построение проекта WcfApplicationServices, чтобы убедиться в том, что разметка, код и параметры конфигурации компилируются.

Теперь можно приступить к настройке веб-приложения для предоставления служб приложения.

Настройка служб приложения

Откройте файл Web.config или переключитесь на него.

Между элементами configSections и appSettings добавьте новый элемент system.web.extensions .

Добавьте элемент scripting в элемент system.web.extensions .

В элементе scripting включите службы проверки подлинности, профиля и ролей с помощью раздела webServices .

Одностраничные приложения: создание современных адаптивных веб-приложений с помощью ASP.NET

Продукты и технологии:

Single-Page Applications (SPA), ASP.NET Web API, Knockout.js, Ember.js, AJAX и HTML5

В статье рассматриваются:

  • создание уровня сервисов и веб-клиента AJAX для приложения-примера;
  • шаблоны MVC и MVVM;
  • связывание с данными;
  • создание веб-клиента с применением Knockout.js;
  • создание веб-клиента с применением Ember.js.

Одностраничные приложения (Single-Page Applications, SPA) — это веб-приложения, которые загружают одну HTML-страницу и динамически обновляют ее при взаимодействии с пользователем.

SPA используют AJAX и HTML5 для создания гибких и адаптивных веб-приложений без постоянных перезагрузок страницы. Однако это означает, что большая часть работы возлагается на клиентскую сторону, а именно на JavaScript-код. Разработчику для традиционной ASP.NET может быть трудно совершить такой кульбит. К счастью, существует множество JavaScript-инфраструктур с открытым исходным кодом, которые облегчают создание SPA.

В этой статье я пошагово пройду процесс создания простого SPA-приложения. Попутно вы ознакомитесь с некоторыми фундаментальными концепциями создания SPA, в том числе с шаблонами Model-View-Controller (MVC) и Model-View-ViewModel (MVVM), связыванием с данными и маршрутизацией (routing).

О приложении-примере

Я создал приложение-пример для операций с простой базой данных по фильмам ( рис. 1 ). В крайнем слева столбце страницы отображается список жанров. Выбор жанра приводит к появлению списка соответствующих фильмов. Кнопка Edit рядом с записью позволяет изменять эту запись. После редактирования можно щелкнуть кнопку Save для передачи обновления на сервер или кнопку Cancel для отмены изменений.

Рис. 1. SPA-приложение для базы данных по фильмам

Я создал две версии этого приложения: одна из них использует библиотеку Knockout.js, а другая — библиотеку Ember.js. Эти две библиотеки основаны на разных подходах, поэтому будет весьма поучительно сравнить их. В обоих случаях клиентское приложение не требовало более 150 строк JavaScript-кода. На серверной стороне я задействовал ASP.NET Web API, чтобы обслуживать JSON для клиента. Исходный код обеих версий вы найдете на github.com/MikeWasson/MoviesSPA.

( Примечание Я создавал приложение, используя RC-версию Visual Studio 2013. В RTM-версии некоторые вещи могли измениться, но они не должны повлиять на код.)

Обзор

В традиционном веб-приложении при каждом вызове сервера тот осуществляет рендеринг новой HTML-страницы. Это вызывает обновление страницы в браузере. Если вы когда-нибудь писали приложение Web Forms или PHP, этот жизненный цикл страниц должен быть знаком вам.

В SPA после загрузки первой страницы все взаимодействие с сервером происходит через AJAX-вызовы. Эти AJAX-вызовы возвращают данные (не разметку) — обычно в формате JSON. Приложение использует JSON-данные для динамического обновления страницы без ее перезагрузки. Рис. 2 иллюстрирует разницу между этими двумя подходами.

Рис. 2. Сравнение традиционного жизненного цикла страницы с жизненным циклом в SPA

Примечание
Traditional Page Lifecycle Традиционный жизненный цикл страницы
Client Клиент
Page Reload Перезагрузка страницы
Server Сервер
Initial Request Начальный запрос
HTML HTML
Form POST Передача формы командой POST
SPA Lifecycle Жизненный цикл в SPA
AJAX AJAX
JSON JSON

Одно из преимуществ SPA очевидно: приложения более гибкие и адаптивные, свободные от рваного эффекта перезагрузки страницы и ее рендеринга заново. Другое преимущество может оказаться менее очевидным и касается того, как вы проектируете архитектуру веб-приложения. Отправка данных приложения как JSON обеспечивает разделение между презентационной частью (HTML-разметкой) и прикладной логикой (AJAX-запросы плюс JSON-ответы).

Это разделение упрощает проектирование и развитие каждого уровня. В SPA-приложении с тщательно продуманной архитектурой можно изменять HTML-разметку, не касаясь кода, который реализует прикладную логику (по крайней мере, в идеале). Вы увидите это на практике, когда мы будем обсуждать связывание с данными.

В чистом SPA все UI-взаимодействие происходит на клиентской стороне через JavaScript и CSS. После начальной загрузки страницы сервер действует исключительно как уровень сервисов. Клиенту нужно просто знать, какие HTTP-запросы он должен посылать. Ему не важно, как сервер реализует свою часть.

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

Создание проекта в Visual Studio

В Visual Studio 2013 есть один тип проекта ASP.NET Web Application. Мастер этого проекта позволяет выбрать ASP.NET-компоненты, которые будут включены в проект. Я начал с шаблона Empty, а затем добавил в проект ASP.NET Web API, установив флажок Web API в разделе Add folders and core references for, как показано на рис. 3 .

Рис. 3. Создание нового ASP.NET-проекта в Visual Studio 2013

В новом проекте есть все библиотеки, необходимые для Web API, а также кое-какой конфигурационный код Web API. Я не вводил никаких зависимостей от Web Forms или ASP.NET MVC.

Обратите внимание на рис. 3 , что Visual Studio 2013 включает шаблон Single Page Application. Этот шаблон устанавливает скелет SPA-приложения, основанный на Knockout.js. Он поддерживает вход с применением базы данных с информацией о членстве в группах или с помощью внешнего провайдера аутентификации. Я не стал использовать этот шаблон в своем приложении, потому что хотел показать более простой пример с нуля. Шаблон SPA — отличный ресурс, особенно если вам нужно добавить аутентификацию в приложение.

Создание уровня сервисов

Я использовал ASP.NET Web API, чтобы создать простой REST API для приложения. Не буду здесь вдаваться в детали Web API — подробности вы можете прочитать по ссылке asp.net/web-api.

Сначала я создал класс Movie, представляющий фильм. Этот класс делает две вещи:

  • сообщает Entity Framework (EF), как создавать таблицы базы данных для хранения информации о фильмах;
  • сообщает Web API, как форматировать полезные данные JSON.

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

  1. namespace MoviesSPA.Models
  2. <
  3. public class Movie
  4. <
  5. public int ID < get; set; >
  6. public string Title < get; set; >
  7. public int Year < get; set; >
  8. public string Genre < get; set; >
  9. public string Rating < get; set; >
  10. >
  11. >

Затем я воспользовался технологией scaffolding в Visual Studio для создания контроллера Web API, который задействует EF в качестве уровня данных. Чтобы применить эту технологию, щелкните правой кнопкой мыши папку Controllers в Solution Explorer и выберите Add / New Scaffolded Item. В мастере Add Scaffold укажите Web API 2 Controller with actions, using Entity Framework, как показано на рис. 4 .

Рис. 4. Добавление контроллера Web API


На рис. 5 приведен мастер Add Controller. Я присвоил контроллеру имя MoviesController. Имя имеет значение, так как URI для REST API основываются на имени контроллера. Я также установил флажок Use async controller actions, чтобы задействовать преимущества новой функциональности async в EF 6. Я выбрал класс Movie в качестве модели и указал New data context, чтобы создать новый контекст данных EF.

Рис. 5. Мастер Add Controller

Мастер добавляет два файла:

  • MoviesController.cs — определяет контроллер Web API, который реализует REST API для приложения;
  • MovieSPAContext.cs — это в основном склеивающий слой EF, который предоставляет методы для запроса нижележащей базы данных.

В табл. 1 показан REST API по умолчанию, создаваемый технологией scaffolding.

Табл. 1. REST API по умолчанию, созданный технологией scaffolding из Web API

HTTP-команда URI Описание
GET /api/movies Получить список всех фильмов
GET /api/movies/ Получить фильм с идентификатором, равным
PUT /api/movies/ Обновить фильм с идентификатором, равным
POST /api/movies Добавить новый фильм в базу данных
DELETE /api/movies/ Удалить фильм из базы данных

Значения в фигурных скобках являются заменителями для подстановки. Например, чтобы получить фильм с идентификатором, равным 5, URI должен выглядеть так: /api/movies/5.

Я расширил этот API, добавив метод, который находит все фильмы указанного жанра:

  1. public class MoviesController : ApiController
  2. <
  3. public IQueryable GetMoviesByGenre(string genre)
  4. <
  5. return db.Movies.Where(m =>
  6. m.Genre.Equals(genre, StringComparison.OrdinalIgnoreCase));
  7. >
  8. // Остальной код не показан

Клиент указывает жанр в строке запроса URI. Например, чтобы получить все фильмы жанра Drama, клиент посылает GET-запрос на /api/movies?genre=drama. Web API автоматически связывает параметр запроса с параметром genre в методе GetMoviesByGenre.

Создание веб-клиента

До сих пор я просто создавал REST API. Если вы отправите GET-запрос на /api/movies?genre=drama, исходный HTTP-ответ будет выглядеть так:

Теперь мне нужно написать клиентское приложение, которое делает с этим что-то осмысленное. Базовый рабочий процесс такой:

  • UI инициирует AJAX-запрос;
  • обновляем HTML для отображения полезных данных ответа;
  • обрабатываем AJAX-ошибки.

Вы могли закодировать все это вручную. Например, вот некоторый jQuery-код, который создает список названий фильмов:

  1. $.getJSON(url)
  2. .done(function (data) <
  3. // При успехе data содержит список фильмов
  4. var ul = $(» «)
  5. $.each(data, function (key, item) <
  6. // Добавляем элемент в список
  7. $(‘
  8. ‘, < text: item.Title >).appendTo(ul);
  9. >);
  10. $(‘#movies’).html(ul);
  11. >);

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

Решение заключается в том, чтобы использовать JavaScript-инфраструктуру. К счастью, их выбор довольно велик, и эти инфраструктуры имеют открытый исходный код. К некоторым из более популярных инфраструктур относятся Backbone, Angular, Ember, Knockout, Dojo и JavaScriptMVC. Большинство использует вариации шаблонов MVC или MVVM, поэтому будет полезно вкратце рассмотреть эти шаблоны.

Шаблоны MVC и MVVM

Корни шаблона MVC уходят в 80-е годы прошлого века и связаны с ранними графическими UI. Цель MVC — разбиение кода на три уровня со своими обязанностями ( рис. 6 ). Вот что они делают:

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

Рис. 6. Шаблон MVC

View View
Controller Controller
Model Model
User Input Пользовательский ввод
Updates Обновления
Modifies Модифицирует

Более современная вариация MVC — шаблон MVVM ( рис. 7 ). В шаблоне MVVM:

  • модель по-прежнему представляет данные предметной области;
  • модель представления — это абстрактное отражение представления;
  • представление отображает модель представления и посылает пользовательский ввод модели представления.

Рис. 7. Шаблон MVVM

View Model View Model

В JavaScript-инфраструктуре MVVM представлением является разметка, а моделью представления — код.

MVC имеет много вариаций, а литература по MVC зачастую противоречива и запутана. По-видимому, это и не удивительно для проектировочного шаблона, который начал свою жизнь со Smalltalk-76 и все еще применяется в современных веб-приложениях. Поэтому, хоть и хорошо знать теорию, главное — понимать конкретную инфраструктуру MVC, используемую вами.

Создание веб-клиента с применением Knockout.js

Для первой версии своего приложения я использовал библиотеку Knockout.js. Knockout следует шаблону MVVM, соединяя представление и модель представления через связывание с данными.

Чтобы создать привязки данных, вы добавляете к HTML-элементам специальный атрибут data-binding. Например, следующая разметка связывает элемент span со свойством genre в модели представления. Всякий раз, когда изменяется значение genre, Knockout автоматически обновляет HTML:

Привязки также могут работать в другом направлении, скажем, если пользователь вводит текст в поле, Knockout обновляет соответствующее свойство в модели представления.

Удобно, что связывание с данными осуществляется декларативно. Вам не требуется подключать модель представления к элементам HTML-страницы. Просто добавьте атрибут data-binding, и Knockout сделает остальное.

Я начал с создания HTML-страницы с базовой разметкой без связывания с данными, как показано на рис. 8 .

Построение приложений на основе шаблона «Model-View-Controller» с применением ASP.NET MVC Framework

Обзор ASP.NET MVC Framework

После появления на свет платформы ASP . NET и инструмента ASP . NET для создания Web Forms она стала пользоваться большой популярностью среди разработчиков веб-приложений. Однако, мировая практика разработки приложений на ASP . NET Web Forms показала, что такой подход может способствовать смешиванию программного кода бизнес-логики с кодом представления. Особенно это характерно для неопытных разработчиков. Другими словами, разработчики создают приложения на основе ASP . NET Web Forms так, что код страницы содержит элементы логики, которые правильно бы было разместить в отдельных объектах. Кроме того, в типичных приложениях на основе ASP . NET Web Forms как правило отсутствуют элементы формирования «читаемых» адресов страниц. Также ASP . NET Web Forms провоцирует к появлению лишних элементов в HTML -разметке страницы (например, содержимое полей ViewState). Эти и другие проблемы, связанные с разработкой на основе ASP . NET Web Forms привели к появлению еще одного инструмента разработки веб-приложений в составе ASP . NET – ASP . NET MVC Framework.

В основе идеологии ASP . NET MVC Framework лежит идея разделения кода на три составляющие – модель (бизнес-логика), контроллер (обработка пользовательского ввода) и представление (генерируемый HTML -код). Эта идея описана в рамках шаблона проектирования » Model -View- Controller » (MVC), который применяется при разработке различных типов приложений; веб-приложения – это лишь один из примеров применения этого шаблона проектирования.

На самом деле использовать шаблон » Model -View- Controller » можно и в рамках ASP . NET Web Forms. Однако, как показывает практика, это делают лишь опытные профессионалы, которые долгое время занимаются разработкой веб-приложений. По умолчанию шаблоны проектов ASP . NET Web Forms не содержат упоминаний об этом шаблоне проектирования, и реализация этого шаблона полностью ложится на плечи разработчика.

Как уже упоминалось, основная идея шаблона проектирования » Model -View- Controller » состоит в том, что функциональность каждого пользовательского сценария разбивается на три части – модель, представление и контроллер . Модель в данном случае является тем местом, где реализуется вся бизнес-логика, определяются бизнес-процессы , происходит взаимодействие с уровнем доступа к данным и т.д. Кроме того, модель, как правило, определяет все базовые сущности, с которыми впоследствии оперируют остальные уровни.

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

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

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

Такое разделение программного кода позволяет добиться нескольких положительных эффектов, которые получаются из-за четкого разделения ответственности между объектами:

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

Конечное преимущество кода с разделением ответственности сводится к более низкой связности компонентов системы, что с точки зрения практики разработки приложения является показателем более высококачественного программного кода.

Отдельным механизмом, заслуживающего внимания, является механизм маршрутизации запросов внутри приложения. Этот механизм позволяет определить шаблоны адреса HTTP и сопоставить различным адресам соответствующие контроллеры и их операции .

Таким образом, процесс обработки запроса в приложении на базе ASP . NET MVC Framework протекает следующим образом:

  • поступает запрос от клиента;
  • на основании таблицы маршрутов выбирается первый подходящий для данного адреса маршрут;
  • на основе выбранного маршрута выбирается необходимый контроллер, который будет заниматься обработкой этого запроса;
  • на основе запроса внутри контроллера выбирается действие (метод класса), которое должно быть выполнено;
  • при выполнении действия контроллера обрабатывается пользовательский ввод и другие параметры, которые влияют на функционирование приложения, а также выбирается представление и генерируются данные для него; также на данном этапе может осуществляться работа с моделью;
  • представление на основе полученных данных генерирует содержимое, которое будет отправлено клиенту (как правило, код HTML);
  • полученное содержимое передается клиенту и жизненный цикл запроса прекращается.

Для того, чтобы разрабатывать веб-приложения на основе ASP . NET MVC Framework необходимо загрузить соответствующую библиотеку с веб-сайта Microsoft. После установки этой библиотеки в составе Visual Studio появится дополнительный тип проекта – ASP . NET Web Application .

После создания нового приложения ASP . NET MVC Framework будет создана заготовка проекта, который имеет следующую структуру:

Как видно, проект ASP . NET MVC Framework имеет строго определенную структуру папок, в рамках которых размещаются соответствующие программные компоненты.

Обычно при разработке приложений на основе ASP . NET MVC Framework следующие папки содержат программные компоненты:

  • в папке «Controllers» размещаются все контроллеры, которые доступны в рамках приложения;
  • в папке «Models» содержатся все объекты бизнес-логики;
  • в папке «Views» содержаться все представления (страницы).

Кроме того, в составе приложения имеются дополнительные папки, которые содержат вспомогательные элементы:

  • папка «Content» содержит таблицы стилей (CSS), изображения и другие элементы, необходимые для генерации пользовательского интерфейса приложения;
  • папка «Scripts» содержит программный код на языке JavaScript, который выполняется в браузере на стороне клиента.

Таким образом, платформа ASP . NET MVC Framework стала дополнительной альтернативой ASP . NET Web Forms, которую можно использовать при разработке приложений на базе ASP . NET .

Краткие итоги

ASP . NET MVC Framework – это новая технология, которая является альтернативой подходу ASP . NET Web Forms. В рамках ASP . NET MVC Framework разработка ведется на основе шаблона проектирования » Model -View- Controller «. Благодаря этому весь программный код разделяется на модель (бизнес-логику), представление (правила генерации кода HTML ) и контроллер (правила обработки пользовательского ввода). Такое разделение позволяет снизить связность компонентов системы, что положительно влияет на качество разрабатываемого программного кода.

Asp построение приложений asp

Этот текст предназначен для тех, кто никогда не имел дела с ASP и вообще смутно себе представляет возможности программирования на стороне сервера. Я ставил себе задачу создать у читателя общее представление о предмете. Отдельные неточности при этом менее важны — пожалуйста, громко не ругайтесь.

Общие сведения

ASP (Active Server Pages) – это мощная технология от Microsoft, позволяющая легко разрабатывать приложения для WWW. ASP работает на платформе Windows NT и IIS (Internet Information Server), начиная с версии 3, хотя вроде есть реализации на других платформах. ASP – это не язык программирования, это внутренняя технология, позволяющая подключать программы к Web-страницам. Основа успеха ASP – простой скриптовый язык (Visual Basic Script или Java Script) и возможность использования внешних COM-компонент.

Как это все происходит?

Вы пишете программу и складываете в файл на сервере. Браузер клиента запрашивает файл. Файл сначала интерпретируется сервером, на выходе производится HTML-код. Этот HTML посылается клиенту. Файлы с программами имеют расширение .asp. Файлы asp – это обычные текстовые файлы, содержащие исходные тексты программ. Файлы делаются с помощью любого текстового редактора. Каталог, в котором размещены файлы asp должен иметь права на выполнение, так как сервер исполняет эти файлы, когда браузер их запрашивает. Собственно программы пишутся на любом скриптовом языке, который установлен в системе. По умолчанию поддерживаются VBScript и JavaScript. Можно доустановить другие (например, Perl). Если ничего специально не указывать используется VBScript. В дальнейшем будем ссылаться только на него. Программные фрагменты заключаются в скобки . Можно ставить открывающую скобку в начале файла, закрывающую – в конце, все что между ними – программа на Visual Basic’е.

Какие средства есть для программирования?

Web – нормальная среда программирования, если правильно понять, что есть что. В VBScript есть все нормальные конструкции структурного программирования (if, while, case, etc). Есть переменные (описывать не обязательно, тип явно не задается). Поддерживаются объекты. Работа с ними обычная – Object.Property, Object.Method. Есть ряд встроенных объектов (Request, Response, Session, Server, Connection, Recordset). Можно доустанавливать другие компоненты (скачивать, покупать, программировать), например для работы с электронной почтой.

Вывод

Понятия «экран», куда можно выводить данные нет. Все, что надо показать пользователю, выбрасывается в выходной поток на языке HTML. Браузер пользователя интерпретирует этот HTML. Для упрощения вывода существует объект Response . Вывод осуществляется с помощью метода Write .

Так производится запись во внутренний буфер объекта Response. Когда скрипт заканчивает работу, весь буфер выдается клиенту. Надо заметить, что клиент получает «чистый» HTML, таким образом программы на ASP не зависят от клиентского ПО, что очень важно. Если внутри выводимой строки нужно использовать кавычку, кавычка удваивается. Другие методы и свойства Response позволяют управлять выводом. Так Response.Buffer регулирует, получает ли клиент данные по мере из записи в Response, или все сразу по завершении исполнения страницы. Метод Response.Redirect перенаправляет браузер на другую страницу. Чтобы им пользоваться, нельзя до него на странице использовать Response.Write.

Программа на ASP не может явно спросить пользователя о чем-то. Она получает данные из других страниц, либо через URL. Передаваемые параметры помещаются во входной поток и доступны через объект Request . Чтобы передать переменную var в программу test.asp , надо написать:

Чтобы из программы получить значение этой переменной, надо написать:

Несколько переменных разделяется знаком &:

Кроме того, чтобы задавать параметры в URL, можно воспользоваться формами HTML. В вызывающей странице пишем так:

Так это выглядит:

При этом пользователь увидит форму из одного поля ввода (var1), в нем будет значение по умолчанию «default». Второе поле (var2) будет невидимо и будет передавать всегда фиксированное значение «var2value». Кнопка «Submit Form» завершает заполнение формы и передает все переменные на test.asp (action). Если method=»get», переменные передаются через URL (test.asp?var1=default&var2=var2value). Если method=»post», передаются вместе с запросом так, что внешне передача переменных не заметна. В вызываемой программе безразлично, какой метод изпользовался (почти). Если у вас нет специальных аргументов за метод GET, используйте метод POST.

Формы

Формы HTML используются для организации диалога с пользователем. Поддерживаются стандартные элементы управления. Все многообразие задается немногими тэгами:

  • INPUT (с параметром TYPE=)
  • SELECT
  • TEXTAREA

Описание – в документации по HTML.

Взаимосвязь между отдельными страницами

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

Один из методов решения этой проблемы — cookies . Пользователю при первом обращении выдается специальный идентификатор, после этого браузер пользователя предъявляет этот идентификатор при каждом обращении, и сервер может распознать, что это тот же самый пользователь. Пользователь может отключить cookies, в этом случае этот метод не работает.

ASP, используя cookies, предоставляет программисту более простое средство — объект Session (сессия). Сессия стартует, когда новый пользователь обращается к любому asp-файлу приложения. Сессия заканчивается при отсутствии активности пользователя в течение 20 минут, либо по явной команде. Специальный объект Session хранит состояние сессии. Туда можно записывать переменные, которые доступны из любой страницы в этой сессии. Записать данные в этот объект можно просто:

Считать потом еще проще:

Сессия, таким образом, – это еще один метод передачи данных между страницами. Одна страница пишет данные в сессию, другая – берет потом оттуда.

Наряду с объектом Session существует объект Application . Если сессия создается для каждого нового пользователя, до Application существует в единственном экземпляре, и может использоваться всеми страницами приложения.

Управление приложением

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

Нужно «просто» вписать Ваш код на соответствующее место. Нужно заметить, что отлаживать код для global.asa довольно непросто, так как он выполняется при очень специфических обстоятельствах (к примеру при старте или остановке сервера).

Использование внешних компонент

Если на сервере установлены дополнительные компоненты, их можно использовать из ASP. Стандартные объекты (например из библиотек ADO (Connection и Recordset) и Scripting (Dictionary, FileSystemObject)) доступны всегда. Установка новой компоненты обычно состоит в копировании dll-файла в каталог на сервере и ее регистрации с помощью программы regsvr32.exe. [В COM+ используется своя процедура инсталляции объектов, это однако не влияет на использования объектов.]

Создать экземпляр объекта можно так:

Class.Object указываются в документации на компоненту. В переменной var запоминается ссылка на созданный экземпляр объекта. Когда объект не нужен, ссылку нужно обнулить с помощью команды:

Пожалуйста всегда обнуляйте все ссылки на объекты, когда они больше не нужны. Теоретически это должно происходить автоматически при завершении процедуры/страницы, однако в стандартной сборке мусора есть определенные «проблемы».

В остальном использование компоненты зависит от самой этой компоненты.

Работа с базами данных

Из ASP можно легко и просто работать с любыми базами данных. Это делается через две промежуточные технологии: ODBC и ADO.

ODBC позволяет организовать доступ к любым базам данных через унифицированный интерфейс с помощью языка SQL. Специфика конкретных СУБД учитывается при помощи специальных драйверов БД. Такие драйверы существуют для всевозможных СУБД (в частности SQL Server, Oracle, Access, FoxPro). Поддержка ODBC обеспечивается на уровне операционной системы Windows (NT). Настройка – через Control Panel/ODBC. Базовым понятием является источник данных или data source. Источник данных – это совокупность сведений о базе данных, включая ее драйвер, имя компьютера и файла, параметры. Чтобы пользоваться базой надо создать источник данных для нее. Важно, чтобы источник данных был «системным», в отличии от «пользовательского». После этого надо лишь знать имя источника данных. [В настоящее время ODBC отступает перед натиском технологии OLE DB. На практике это однако практически ничего не изменяет. Вместо имени источника данных нужно использовать Connection String, в которой указывается имя ODBC-драйвера и все его параметры.]

ADO – это совокупность объектов, доступных из ASP, позволяющих обращаться к источнику данных ODBC [или OLE DB]. Фактически нужны лишь 2 объекта – Connection , представляющий соединение с базой данных и Recordset , представляющий набор записей, полученный от источника. Сначала необходимо открыть соединение, потом к нему привязать Recordset, потом, пользуясь методами Recordset’а, обрабатывать данные. Вот пример:

Если команда SQL не возвращает данных, recordset не нужен, надо пользоваться методом Conn. Execute (SQL_COMMAND).

Если Вы хотите вызывать хранимые процедуры сервера БД с параметрами, нужно воспользоваться объектом Command , который в свою очеред содержит объекты Parameter .

Методики программирования, советы


Описание переменных

VBScript — очень нетребовательный к программисту язык. Так он не требует описывать переменные и не содержит явных типов данных. Все переменные принадлежат одному типу Variant . Из-за отсутствия описаний могут произойти очень трудно обнаруживаемые ошибки. Одна опечатка может стоить полдня поисков.

Однако, есть возможность явно потребовать описания переменных. Для этого первой строкой в ASP-файле нужно написать Option Explicit . После этого обращение к переменной, которая не была объявлена с помощью Dim , вызывает ошибку с указанием номера строки.

Кстати, где расположены описания Dim в процедуре — совершенно не важно. Они могут стоять как до использования переменной, так и после, и даже в цикле. Видимо они отрабатываются препроцессором. Явно задать тип переменной с помощью Dim Var as Typ , как в Visual Basic, все равно нельзя.

Чередование ASP/HTML

Если нужно выдать большой кусок HTML, можно не пользоваться Response.Write. Если в asp-файле встречается кусок текста вне скобок , он трактуется просто как HTML, который надо вывести. Пример:

Обработка ошибок

Для отслеживания ошибок используется специальный объект Err . Он устанавливается в ненулевое значение, если предыдущая команда породила ошибку. Ее можно проверять с помощью If, и таким образом реагировать на ошибки. Чтобы из-за ошибки не прерывалось выполнение программы, в начале нужно включить команду

Включение других файлов

Можно выносить повторяющийся код в отдельный файл, и подключать к разным другим по мере необходимости с помощью команды include . Это очень удобно, если вы хотите вынести повторяющийся код в отдельный файл и использовать снова и снова в разных страницах:

Важно: все includes в тексте отрабатываются до исполнения файла. Т.е. даже если include стоит внутри if, то сначала будут включены все includes во всех ветках, и только потом, во время исполнения, будет принятно решение, какую ветку выполнять. Т.е. следующий код не дает условного включения файлов:

Обработка форм

Если надо что-то спросить у пользователя и на основании этого что-то сделать, в простейшем случае создается два файла: один с формой, второй – с ее обработчиком. Обработчик выполняет все действия. Пример:

Рекурсивная обработка форм

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

Переменные HTTP

Запрос от браузера, кроме запрашиваемой страницы несет еще некоторые данные. Эти данные, например, IP-адрес клиента, доступны через специальные переменные объекта Request. IP-адрес – Request(«REMOTE_ADDR»). Другие — см.документацию (ASPSamp\Samples\srvvar.asp).

Переадресация

Очень легко написать на ASP скрипт, который будет производить некоторые расчеты, и в зависимости от результатов переадресовывать браузер на разные URL (например, подставлять нужный баннер). Делается это так:

Только надо следить, чтобы до выполнения команды redirect ничего не было записано в Response (даже коментарии HTML).

Электронная почта

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

Но это приводит к тому, что при отправке формы делается попытка на клиентской машине запустить почтовую программу и создать новое сообщение с данными формы. Если это не получается (почтовая программа не настроена, пользователь не отправил почту, и т.д.) — письмо и не будет отправлено. Гораздо надежнее работает серверное решение.

Для этого существуют внешние компоненты, есть и бесплатные. Например, компонента Jmail от Dimac. Все, что для нее нужно – это адрес SMTP-сервера. Вот пример ее использования:

Доступ к объекту приложения, созданному из ASP в ASP.net [дубликат]

Это может быть сумасшедший вопрос (я несколько новичок в ASP.NET). Но возможно ли смешивать код ASP.NET с классическим ASP, например. встроенная форма, созданная в ASP.NET на классической странице ASP?

3 ответа

Нет, вы не можете *

asp-страницы — это простые простые страницы, на которых фактически работают автономные скрипты на стороне сервера, а сервер возвращает результат. Каждая страница одна.

Страницы asp.net — это полная программа, которые связаны друг с другом, потому что они работают под одним пулом, скомпилируют их все вместе в одном каталоге со многими подкаталогами, имеют специальные каталоги и другие опции. Пул, в котором работают страницы, обрабатывает некоторые общие данные, состояния сеанса и многие другие.

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

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

ASP.NET и разработка Web-приложений

Многие разработчики полагают, что технология ASP.NET является чем-то вроде продолжения ASP, т. е. что это, если так можно выразиться, перенесенная на платформу .NET версия ASP 3.0, несколько усовершенствованная и дополненная поддержкой новых языков. Подобное представление в корне неверно. ASP.NET является концептуально новой современной платформой, предназначенной для создания Web-приложений. Специалистами Microsoft в ASP.NET заложено все для того, чтобы сделать цикл разработки Web-приложения более быстрым, а поддержку — более простой.

Для начала мы обсудим новые возможности ASP.NET, и я подчеркну отличия от ASP, чтобы на конкретных примерах продемонстрировать новые принципы построения приложений для Internet, призванные максимально облегчить работу программистов.

Компилирование программного кода. Теперь написанный исходный код при первом обращении компилируется и впоследствии выполняется его скомпилированная версия. Это заметно ускоряет разработку приложений. Web-сервер сам выполняет компиляцию, и если исходный код заменить, то сервер автоматически при первом обращении к странице проведет перекомпиляцию. Тем, кто разрабатывал сервлеты и запускал их на таких Java-серверах, как tomcat, наверняка знакома сложная процедура перезапуска сервера после перекомпиляции. Приходится сначала самому компилировать сервлет, а затем прописывать его в конфигурационный файл, и при каждом изменении вновь перезагружать сервер. С ASP.NET быть разработчиком Web-приложений намного приятнее. Код выполняется быстрее, занимает меньше ресурсов, и при этом процесс разработки не усложнился. Скорее наоборот, так как в случае какого-либо сбоя можно получить полный листинг компилятора, с подробным описанием ошибки.

Библиотеки. Теперь при написании приложений можно задействовать набор компонентов, поставляемых с .NET, а он достаточно велик. Использование библиотеки классов Common Language Runtime (CLR) уменьшает количество кода, ускоряет процесс разработки, установки и переноса приложения.

ADO.NET. В приложениях ASP.NET, как и в любом другом программном коде под .NET, можно использовать ADO.NET. Я упоминаю ADO.NET особо, чтобы подчеркнуть, насколько часто эта библиотека применяется при создании приложений на ASP.NET. Среди функций ADO.NET, используемых в ASP.NET, можно назвать, например, возможность сохранения набора данных в XML и загрузки его из XML, что упрощает разработку распределенных приложений на основе ASP.NET, а также полезно при передаче данных между Web-службами ASP.NET.

Поддержка средств разработки. Visual Studio.NET предоставляет возможность создания и редактирования приложений в режиме WYSWYG, включает в себя средства, упрощающие разработку и перенос приложений, а также отладку сценариев. Но, несомненно, никто не отнимает права написания кода в любимом редакторе, будь то CodeWright, EditPlus или NotePad.

Языковая независимость. ASP.NET работает в рамках Common Language Runtime, что позволяет писать код на любом языке, для которого существует компилятор, поддерживающий эту технологию. Сейчас имеется поддержка для JScript, VB, Perl и C#.

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

Обработка ошибок. В связи с новыми концепциями (в частности, с компиляцией программных текстов) в ASP.NET добавлены более широкие возможности обработки ошибок. На стадии разработки можно получить полную информацию об ошибке и листинг нужного куска кода. Для обработки ошибок, которые могут случиться во время выполнения приложения, можно использовать новую директиву ErrorPage.

Объектно-ориентированная разработка. Использование C# позволяет в полной мере задействовать концепции, методы и шаблоны объектно-ориентированной разработки.

Повторное применение. Помимо возможностей объектно-ориентированного программирования, ASP.NET представляет новые технологии, такие, как пользовательские элементы управления (user controls), новую концепцию установки (bin) и другие возможности.

Набор серверных компонентов ASP.NET. В комплект ASP.NET входят различные серверные компоненты: от самых простых (кнопка, список) до нестандартных и более функционально богатых (календарь).

Структура

Теперь немного поговорим о внутренней организации ASP.NET. Если продолжить сравнение с ASP, надо отметить, что в связи с описанными нововведениями внутренняя организация не могла остаться прежней. Если ASP представляла собой ISAPI DLL, с набором компонентов и несколькими системными файлами, то ASP.NET — часть глобальной платформы .NET. Создание этой платформы — важнейшее направление новой стратегии Microsoft; она соответствует всем современным стандартам разработки как для распределенных систем, так и для настольных приложений. На Рисунке 1 приведена схема, на которой показано взаимодействие различных частей .NET. Взаимодействие строится следующим образом: библиотека .NET Framework предоставляет интерфейс приложениям, а сама при этом взаимодействует непосредственно с операционной системой. Выше лежит интерфейс приложений ASP.NET, на котором, в свою очередь, базируются Web-формы (страницы ASP.NET) и Web-службы. Интерфейс .NET Framework позволяет стандартизировать обращение к системным вызовам и предоставляет среду для более быстрой и удобной разработки.

Рисунок 1. Схема работы .NET.

Intermediate Language — общий промежуточный язык, в который компилируется любой код под .NET, независимо от того, был ли он написан на C#, VB.NET или другом языке, — позволяет создавать системы на любом языке. И независимо от того, используется ли C#, VB.NET, JScript.NET или Perl.NET, на выходе получается готовый к выполнению код. На Рисунке 2 показана схема процесса компиляции и выполнения приложения ASP.NET. При запросе страницы проверяется, есть ли на диске ее скомпилированная версия и не обновлялась ли страница с момента компиляции. Если есть актуальная версия, она подгружается с диска и выполняется средой .NET. Результат выполнения страницы отсылается клиенту. Если же такая версия не была найдена, страница сначала компилируется. Для этого используются соответствующие компиляторы, которым на вход подается исходный код самой страницы, ее code-behind (т. е. непосредственно исполняемый код, стоящий за Web-формой, который написан отдельно — он может отсутствовать) и код элементов управления. Полученный в результате код сохраняется на диске. В некоторых случаях, а именно, когда в кэше имеется сохраненный результат обработки страницы, MSIL-код даже не приходится выполнять.

Рисунок 2. Схема работы ASP.NET.

На практике

Данный процесс кажется сложным, но разработчики всей этой сложности не замечают — процедура создания страниц ASP.NET достаточно проста. В подтверждение своих слов я хочу создать простейшую ASP.NET-форму. Для написания формы нужно сначала установить, собственно, ASP.NET. Установка начинается с получения комплекта .NET Framework SDK. Размер дистрибутива достигает 90 Мбайт, однако имеется возможность загрузки SDK в виде набора маленьких файлов. После загрузки требуется запустить файл setup.exe и следовать его инструкциям. ASP.NET распространяется как составная часть .NET SDK — сборника всех технологий, необходимых для создания, сборки и тестирования приложений, основанных на .NET Framework. Перед установкой ASP.NET следует инсталлировать Internet Explorer 6. NET SDK можно взять и с компакт-диска Windows Component Update из Visual Studio.NET. Если VS.NET на сервере установлен, то для того, чтобы запускать приложения ASP.NET, уже все есть.

Первую форму мы создадим с привлечением минимальных средств — нам падобится .NET Framework, Internet Information Services 5 и текстовый редактор. Создание формы начнем с написания приложения на Web-сервере. Создадим папку, в которой будет находиться приложение. Предположим, C:SampleApplication. Затем запустим Internet Services Manager. Создадим на сервере новый виртуальный каталог. Для этого нужно вызвать контекстное меню Web-сервера и выбрать пункт NewVirtual Director. На экране появится мастер Virtual Directory Creation Wizard. С его помощью нужно указать имя нового приложения, пусть это будет CustomApp. Далее следует указать каталог, в котором будут находиться файлы приложения. В нашем случае это C:SampleApplication. Следующий шаг — назначить права доступа к приложению (их можно оставить заданными по умолчанию). Далее в полученной папке создадим файл Default.aspx (см. Листинг 1).

Листинг 1. Default.aspx.

Опишу вкратце код этого листинга.

В первой строчке стоит директива @ Page, которая задает параметры страницы. Здесь, в частности, указано, что мы пишем на C#, что на странице у нас будет проводиться дополнительная программная обработка, определенная в файле Default.aspx.cs (мы его еще напишем), а наследоваться страница будет от класса Default (который будет описан в файле Default.aspx.cs).

Далее следует форма. Все серверные элементы управления должны быть включены в серверную форму (

Разработка ASP.NET 5 веб-приложений с Visual Studio Code

Введение

10 лет назад трудно было вообразить, что разработка ASP.NET веб-приложений вне интегрированной среды разработки Visual Studio .NET буде возможна. Но в прошлом году произошли изменения. В апреле 2014 года на конференции разработчиков (Build) Microsoft анонсировал запуск нового легкого кросс-платформенного кодового редактора для разработки современных веб-приложений под именем Visual Studio Code.

Visual Studio Code

Visual Studio Code свободна для скачивания с официального сайта. Работаете ли Вы на Linux, Mac или Windows – не имеет значения. Вы можете скачать и запустить VS код на своей платформе.

Установка Visual Studio Code довольно проста, но если Вы застрянете, то всегда можете просмотреть документацию по установке.

Visual Studio Code является просто редактором кода на файловой основе и не имеет всех преимуществ полной интегрированной среды разработки Visual Studio .NET. Он легче по дизайну. Тем не менее, у редактора есть множество особенностей, которые поддерживают такие технологии, как IntelliSense для дополнения кода, Peek Definition для быстрого взгляда на функциональный код без навигации, реорганизацию кода и прочие. Visual Studio Code также поддерживает множество языков, например CoffeeScript, F#, Go, Jade, Java, Handlebars, Powershell и Python, для примера. Вы можете проверить языковую поддержку здесь.

Также Visual Studio Code способен поддерживать такие среды выполнения, как ASP.NET 5 и Node.JS. Если Вы их используете для веб-разработки с Microsoft Stack, можете быть уверенны, что ASP.NET 5 (новая версия ASP.NET) сейчас поддерживает кросс-платформенную разработку. Это значит, что можно разрабатывать ASP.NET-приложение в среде Linux, Mac или Windows так же, как и запускать его в любой из них. И Вам даже не нужно иметь интегрированную среду разработки Visual Studio .NET, чтобы сделать это.

Visual Studio Code – это все, что вам нужно, чтобы начать работать с ASP.NET 5, и это здорово!

Установка ASP.NET 5 & DNX (среды выполнения .NET):

ASP . NET 5 был построен с нуля, чтобы убедиться, что он придерживается современной парадигмы веб-приложений, и что приложения, разработанные с его помощью являются «облачными». Ключевыми аспектами ASP . Net 5 явля ются гибкость и модульность – он предлагает минимальные накладные расходы и позволяет нам выбирать только то, что мы хотим в рамках нашего веб-приложения.

DNX расшифровывается как Dot Net eXecution Environment.

Что такое Yeoman?

Если Вы работали в интегрированной среде разработки Visual Studio .NET, Вам будет интересно: «Есть ли здесь File > New > ASP.NET шаблон проекта?» Visual Studio Code является редактором кода на файловой базе, так что Вы можете просто открыть файл и начать редактирование. Кроме того, нужны поддерживающие средства, чтобы работать с исполняемым шаблоном ASP.NET.

Yeoman является популярным консольным инструментом для автоматического построения структуры проекта, а также обеспечивает базовым ASP.NET шаблоном для старта. Yeoman может быть установлен с помощью NPM, но для начала надо установить Node . JS .

Если у Вас нет Node в системе, можете установить его. Кроме Yeoman , Вам также нужны другие поддерживающие средства, такие как генератор ASP . NET , исполнитель задач Grunt и Bower . Вы можете выполнить это за одну команду. В командной строке набрать следующую команду и нажать enter:

npm install –g yo grunt-cli generator-aspnet bower

Теперь Вы можете строить веб-приложения.

Создание веб-приложения

Разберем пошагово, как построить структуру проекта нового ASP.NET 5 веб-приложения.

1. Откройте командную строку и перейдите в папку, где Вы хотите создать свое новое веб-приложение.

2. Введите в командную строку следующую команду:

3. Yeoman отобразит варианты приложений для генератора aspnet. Возможные варианты:

  • консольное приложение
  • веб-приложение
  • основное веб-приложение (без членов/аутентификации)
  • веб-приложение API
  • Nancy ASP.NET приложение
  • библиотека классов
  • тестовый проект Unit

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

4. Дальше нам нужно назвать веб-приложение. Используем HelloWorld как имя нашего образца ASP . NET 5 веб-приложения. Введите имя и нажмите enter. Yeoman построит структуру проекта.

5. Каталог, в котором будет создано наше веб-приложение будет иметь то же имя, что мы дали только что Yeoman . В данном случае — “ HelloWolrd ”.

6. Через командную строку откройте Visual Studio Code

7. Visual Studio Code запустит проект HelloWorld. Файлы в проекте будут отображаться в окне Проводника.

8. В редакторе Visual Studio Code выберите View > Command Palette option
и в командной палитре введите следующую команду:

dnx: dnu restore — (HelloWorld)

Выше написанная команда restore устанавливает нужные NuGet пакеты, необходимые для запуска веб-приложения. Она запустит командную строку, куда будут загружаться все пакеты. После выполнения будет получено сообщение, что загрузка завершена.

Запуск веб-приложения

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

1. В Visual Studio Code откройте Command Palette, выбрав View > Command Palette. Введите следующую команду для запуска приложения:

dnx: kestrel -(HelloWorld,Microsoft.AspNet.Hosting—server Kestrel–config hosting.ini

Примечание: Когда Вы начинаете набирать команду, командная палитра подскажет Вам полную команду в списке. Вы можете выбрать команду из списка и команда будет выполнена.

2. Откройте браузер и перейдите по ссылке http://localhost5000

Мы только что создали ASP.NET веб-приложение вне интегрированной среды разработки Visual Studio. Фактически, в настоящее время ASP.NET больше не только в Windows. Мы переходим на кросс-платформу – как с точки зрения разработки, так и размещения.

Интеграция Telerik UI для набора ASP.NET MVC

Teleric предлагает пользовательский интерфейс, известный как UI для ASP.NET MVC. Он произошел от Kendo UI и предусматривает HTML-помощников, которых называют “Kendo UI wrappers.” Они упрощают работу с элементами управления Kendo UI и ускорят вашу разработку.

Представим пошагово добавление пользовательского интерфейса для ASP.NET MVC в наш проект:

1. Откройте файл project.json и в узле (“dependencies”) добавьте Kendo (в настоящее время доступна бинарная версия Kendo Mvc – 2015.2.805).

2. Дальше откройте Startup.cs и найдите метод “ConfigureServices”. Добавьте следующий фрагмент в метод.

//Register UI for ASP.NET MVC Helpers

3. Затем откройте

/Views/_ViewImports.cshtml и импортируйте пространство имен Kendo.Mvc.UI .

@using Kendo . Mvc . UI

4. Скопируйте Kendo UI ресурс с клиентской стороны. Для этого Вам нужно установить пакет Kendo UI Professional (Commercial Package). Его можно установить через Bower с помощью следующей команды:

bower install https://bower.telerik.com/bower-kendo-ui.git

Пакет Kendo UI Professional Bower размещается в частном git -хранилище и требует активировать аккаунт Telerik. Во время установки Вам предложат ввести пароль несколько раз.

Bower установит пакет Kendo UI Professional как “ kendo — ui ” в папку wwwroot / lib .

5. Дальше нам необходимо зарегистрировать скрипты Kendo UI и стили в

link rel =»stylesheet» href =»

link rel =»stylesheet» href =»

link rel =»stylesheet» href =»

6. Теперь давайте используем виджет Kendo UI в одном из видов. Мы будем использовать виджет Kendo UI DatePicker. Откройте

/Views/Home.Index.cshtml и добавьте следующий фрагмент:

@RenderSection(«scripts», required: false)

7. Запустите веб-приложение через dnx: kestrel команду, что мы использовали ранее. Результат представлен ниже.

ASP.NET веб-приложение и веб-сайт

Веб-проект ASP.NET можно создавать как приложение и как сайт. Конечная цель этих видов проектов рабочий веб-сайт, размещенный на сервере. Создавать интернет проекты можно скомпилировав весь программный код (находящийся в многочисленных файлах) в сборку .dll (веб-приложение) или же разместить текстовые файлы с программным кодом непосредственно на сервере (веб-сайт) для динамической компиляции при загрузке веб-страниц. Выбрать ту или иную схему построения помогают теоретические знания и опыт работы с различных типами веб-проектов.

Просмотр содержимого веб-приложения и веб-сайта в MS Visual Studio. В веб-приложении файлы исключенные из проекта, по умолчанию, невидимы и просмотреть все файлы можно нажав кнопку показа всех файлов, при этом исключенные файлы будут выделены прямоугольником из точек. Данная опция отключения видимости дает возможность сосредоточиться только на рабочих файлах проекта. В проекте веб-сайта видны все файлы, исключенные из проекта файлы маркируются расширением .exclude, но не скрываются (наверняка в следующих версиях Visual Studio появится возможность скрывать их). Интересно, что можно открыть любую папку в компьютере с помощью Visual Studio или WebMatrix и она будет интерпретироваться как веб-сайт. При публикации файлы исключенные из любого веб-проекта на сервер не переносятся. Работая в веб-приложении программный код можно помещать в любые папки, но не желательно использовать название для папки App_Code, эта папка зарезервирована для веб-сайта и при запуске веб-проекта в Visual Studio возможна двойная компиляция (хотя после публикации на сервер нормальная работа восстанавливается). Программный код веб-сайта напротив можно помещать только в папку App_Code. Для удобства, в вебприложении и в веб-сайте, разрешено использовать вложенность папок любой глубины.

Веб-приложения ASP.NET создаются в Visual Studio, все файлы классов с выделенным кодом и отдельные файлы классов в проекте компилируются в единую сборку, которая помещается в папку Bin проекта веб-приложения. Файлы же ASPX и ASCX компилируются динамически на сервере подобно функциональности веб-сайта.

Веб-сайты ASP.NET можно создавать и редактировать в Visual Studio, в WebMatrix и даже используя простой текстовый редактор Блокнот. Компилировать веб-сайт не требуется. В большинстве случаев проекты веб-сайтов компилируются автоматически с помощью .NET Framework на сервере IIS. Можно выбрать режим пакетной компиляции, в котором обычно создается одна сборка для каждой папки, или режим фиксированной компиляции, в котором обычно создается одна сборка для каждой страницы или пользовательского элемента управления. Данная настройка фиксируется в файле конфигурации веб-узла web.config.

Проекты веб-приложений желательно выбирать когда:

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

Проекты веб-сайтов являются предпочтительным вариантом выбора когда:

  • Исходные файлы приложения копируются на сервер IIS.
  • В один веб-проект необходимо включить как код C#, так и код на другом языке .NET.
  • Необходимо открыть рабочий веб-сайт в Visual Studio или WebMatrix и обновить его в режиме реального времени через протокол FTP.
  • Если требуется создать отдельную сборку для каждой страницы, папки или пользовательского элемента
  • Требуется возможность обновления отдельных файлов в рабочей среде путем простого копирования новых версий на рабочий сервер либо путем непосредственного редактирования файлов на рабочем сервере.
  • Вы хотите сохранить исходный код на рабочем сервере в качестве дополнительной резервной копии.

Использование файлов проектов веб-приложений предоставляет следующее преимущества:

  • Можно с легкостью временно удалять файлы из сайта и сохранять их отслеживание, поскольку они остаются в структуре папок. Например, если страница не готова для развертывания, можно временно исключить ее из построения, не удаляя из структуры папок.
  • Скомпилированную сборку можно развернуть, а затем снова добавить файл в проект.

Использование проектов веб-сайтов предоставляет следующие преимущества:

  • Для управления структурой проекта не требуются специализированные инструменты обработки программного и html кода.
  • Можно редактировать файлы простейшим текстовым редактором, например Блокнотом, и копировать файлы в проект или удалять их из него с помощью проводника Windows.

К статье прикреплены исходники примеров веб-приложения и веб-сайта. Исходники созданы в MS Visual Studio 2013 Express, MS Visual Studio 2013, могут быть открыты в Visual Studio 2012. Веб-сайт может быть открыт еще и в WebMatrix или использовать для редактирования веб-сайта любой текстовый редактор.

Илон Маск рекомендует:  Что такое код filepro
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL