ЖАНРЫ

Шрифт:

<add name="ScriptHandlerFactory" verb="*"

path="*.asmx" preCondition="integratedMode"

type="System.Web.Script.Services.ScriptHandlerFactory,

System.Web.Extensions"/>

<add name="ScriptHandlerFactoryAppServices" verb="*"

path="*_AppService.axd" preCondition="integratedMode"

type="System.Web.Script.Services.ScriptHandlerFactory,

System.Web.Extensions"/>

<add name="ScriptResource" preCondition="integratedMode"

verb="GET,HEAD" path="ScriptResource.axd"

type="System.Web.Handlers.ScriptResourceHandler,

System.Web.Extensions" />

<add name="MvcHttpHandler" preCondition="integratedMode" verb="*"

path=" *.mvc" type=" System.Web.Mvc.MvcHttpHandler,

System.Web.Mvc"/>

<add name="UrlRoutingHandler" preCondition="integratedMode"

verb="*" path="UrlRouting.axd"

type="System.Web.HttpForbiddenHandler, System.Web" />

</handlers>

</system.webServer>

Листинг 2.11.

Регистрация пространств имен в файле web.config

<pages>

<namespaces>

<add namespace="System.Web.Mvc"/>

<add namespace="System.Web.Mvc.Ajax"/>

<add namespace="System.Web.Mvc.Html"/>

<add namespace="System.Web.Routing"/>

<add namespace="System.Iiinq"/>

<add namespace="System.Collections.Generic"/>

</namespaces>

Листинг 2.12. Таблица маршрутизации в файле Global.asax

public static void RegisterRoutes(RouteCollection routes)

{

routes.IgnoreRoute("{resource}.axd/{*pathInfo}") ;

routes.IgnoreRoute("{resource}.aspx/{*pathInfo}");

routes.MapRoute("Default", "{controller}/{action}/{id}",

new { controller = "Home", action = "Index", id = "" });

}

protected void Application_Start

{

RegisterRoutes(RouteTable.Routes);

}

Рис. 2.5. Структура WebForms-приложения после добавления MVC-компонентов

После того как все необходимые шаги выполнены, можно продолжать пользоваться WebForms-приложением, а также использовать только что добавленные контроллер и представление, например, создав контроллер Home (листинг 2.13) и представление Index (листинг 2.14), можно получить при обращении по пути /Home/Index результат, представленный на рис. 2.6.

Листинг 2.13. Файл HomeController.cs

using System.Web.Mvc;

namespace WebFormsMvcInterop.Controllers {

public class HomeController : Controller {

public ActionResult Index

{

return View;

}

}

}

Листинг 2.14. Файл Index.aspx

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//

EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title></title>

</head>

<body>

<h1>Hello from MVC</h1>

</body>

</html>

Заключение

В этой главе мы рассмотрели достоинства и недостатки MVC Framework в сравнении с WebForms, а также возможности совместного использования этих технологий

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

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

ГЛАВА 3

Модель и доступ к данным

Согласно паттерну проектирования MVC основное назначение модели — это определение объекта приложения, представлением которого является вид (View). Модель и вид отделены друг от друга и взаимодействуют только в виде оповещений: изменившись, модель оповещает вид, который, согласно новым данным, изменяет свое состояние. Со своей стороны, вид обращается к модели для получения актуальных данных для отображения.

Структура этой главы построена так, что мы начнем рассмотрение построения доступа к данным с обзора механизма Object Relation Mapping, его истории, развития и того, какие механизмы ORM присутствуют в .NET. Мы рассмотрим технологию LINQ, LINQ для SQL, Entity Framework. После этого на простом примере разберем принцип организации эффективного доступа к данным в проектах ASP.NET MVC. В конце главы вас ждет раздел, в котором описаны наиболее популярные механизмы доступа к данным.

Задача получения доступа к данным из кода программы достаточно неординарна по своей природе. С одной стороны, нам хотелось бы иметь возможность оперировать сущностями данных, например, при наличии сущности "Заказчики" (таблица Customers), мы бы хотели иметь в коде возможность оперировать списками заказчиков, иметь возможность добавлять, удалять и изменять данные заказчиков. С другой стороны, мы бы не хотели, чтобы происходило смешивание кода бизнес-логики с такими данными, как строки SQL-запросов, что может привести к самым плачевным последствиям: от нечитабельности кода до непонятных и трудно диагностируемых ошибок или дыр в безопасности в виде SQL-инъекций. Чтобы избежать этого, мы хотели бы отказаться от написания запросов к нашему источнику данных на свойственном базе данных языке (например, построение строк SQL-запросов или разбор XML-файлов), внедрив некую прослойку между данными и операциями над ними. Такой прослойкой, которая с одной стороны предоставит нам полный контроль над данными, а с другой, позволит оперировать над ними в нужном нам стиле, становится ORM.

ORM — это аббревиатура от Object Relation Mapping или, по-русски, объектно-реляционная проекция. Очень легко объяснить сущность ORM: это механизм, который отображает на объекты объектно-ориентированного языка программирования сущности источника данных. Таким образом, одна запись таблицы Customers реляционной СУБД отображается в класс Customer в вашем коде (рис. 3.1).

Рис. 3.1. Отображение сущности базы данных в класс на языке C#

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

? высокий порог вхождения для новичка, тогда как использование распространенного стороннего ORM предполагает большую вероятность того, что новичок знаком с ним;

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

Поделиться с друзьями: