Programming is Fun

DomainModel은 모두다 구성이 마쳐진 상태로 가정하고 MVC에 구성하는 방법에 대해서 알아본다.

먼저, web.config에 configSections에 castle속성과 IRepository에 대한 속성을 등록하고, httpModules에 Lifestyle에 대한 module을 등록한다.

	
		

	
	
		
			
				
					Data Source=HOME-PC\SQLEXPRESS;Initial Catalog=SportsStore;Integrated Security=True;Pooling=False
				
			
		
	

    
      
    

다음, WindsorControllerFactory를 생성한다. WindsorControllerFactory는 DefaultControllerFactory를 상속하며, ControllerInstance를 저장하고 반환하는데 사용된다.

public class WindsorControllerFactory : DefaultControllerFactory
{
    private WindsorContainer container;

    public WindsorControllerFactory()
    {
        container = new WindsorContainer(new XmlInterpreter(new ConfigResource("castle")));
        var controllerTypes = from t in Assembly.GetExecutingAssembly().GetTypes() 
                              where typeof(IController).IsAssignableFrom(t) select t;
        foreach(Type t in controllerTypes)
        {
            container.AddComponentWithLifestyle(t.FullName, t, LifestyleType.Transient);
        }
    }

    protected override IController GetControllerInstance(System.Web.Routing.RequestContext requestContext, Type controllerType)
    {
        return (IController)container.Resolve(controllerType);
    }
}

마지막으로 Controller의 생성자를 이용해서 사용될 DomainModel의 interface를 등록하는 것으로 완료할 수 있다.

public class ProductController : Controller
{
    private IProductRepository _productRepository;
    public ProductController(IProductRepository productRepository)
    {
        _productRepository = productRepository;
    }


    public ViewResult List()
    {
        return View(_productRepository.Products.ToList());
    }
}

상당히 간단한데 왜 외워지지가 않는 것일까.; Castle에 대해서는 두번째 포스트인데 포스트 내용이 비스무리하다. -_-

.NET Framework 4.0Beta2 로 작성된 application들은 NUnit에서 테스트가 불가능하다. NUnit는 .NET 2.x대의 base assembly만이 테스트가 가능하도록 작성되어 있기 때문이다.

그래서 MS의 xUnit test 를 이용해서 RouteData Test Code를 작성해보면 다음과 같다.
먼저, 가장 기본적인 RouteCollection을 생성하고, 테스트할 MVC application의 Route를 등록시킨다.
그리고 RouteCollection.GetRouteData(HttpBaseContext)를 이용해서 들어온 HttpBaseContext에 대한 RouteData를 확인한다.

[TestMethod]
public void TestMethod1()
{
    RouteCollection routeConfig = new RouteCollection();
    RouteApp.MvcApplication.RegisterRoutes(routeConfig);    
    RouteData routeData = routeConfig.GetRouteData(HttpBaseContext);
}

문제는 HttpBaseContext를 생성하는 것인데. Mock을 이용하면 간단하게 해결 할 수 있다.
다음 코드는 Mock을 이용해서 HttpBaseContext를 생성하는 코드이다.

private static Mock MakeMockHttpContext(string url)
{
    var mockHttpContext = new Mock();

    var mockRequest = new Mock();
    //HttpContext에 Request 설정
    mockHttpContext.Setup(x => x.Request).Returns(mockRequest.Object);
    //HttpRequest의 relative url로 사용자 지정 url 설정
    mockRequest.Setup(x => x.AppRelativeCurrentExecutionFilePath).Returns(url);

    var mockResponse = new Mock();
    //HttpContext에 Response 설정
    mockHttpContext.Setup(x => x.Response).Returns(mockResponse.Object);
    //HttpResponse에서 사용자 Url을 그냥 pass시키도록 ApplyAppPathModifier 수정
    mockResponse.Setup(x => x.ApplyAppPathModifier(It.IsAny())).Returns(x => x);            

    return mockHttpContext;
}

최종적으로 완성된 코드는 다음과 같다.

[TestMethod]
public void TestMethod1()
{
    RouteCollection routeConfig = new RouteCollection();
    RouteApp.MvcApplication.RegisterRoutes(routeConfig);

    var mockHttpContext = MakeMockHttpContext("~/");
    RouteData routeData = routeConfig.GetRouteData(mockHttpContext.Object);

    Assert.IsNotNull(routeData.Route);            
    Console.WriteLine(routeData.Values.ToString());
}

: RouteBase, Route, RouteCollection

응용프로그램은 하나의 System.Web.Routing.RouteTable.Routes를 가지며, 응용프로그램의
실제 동작하는 Routing 구성 설정을 갖는다.

ASP.NET MVC에서 구성되는 Global.asax에서 application_start()로 구현이 된다.


Route의 동작

1. Url 요청
2. UrlRoutingModule module 호출(System.Web.Routing)
3. System.Web.Routing.RouteTable.Routes 안에서 요청과 일치하는 RouteBase 객체 반환
4. RouteData 구조체 확인
   1) RouteHandler : 요청을 처리할 객체 (ASP .NET MVC에서는 MvcRouteHandler의 instance가 된다.)
   2) RouteValueDictionary : 요청에서 추출된 중괄호 매개변수의 이름과 값의 dictionary
   3) Route : RouteBase에 대한 참조 객체
   4) DataTokens : Routing Entry에 의해 제공되는 모든 추가적인 구성 설정 옵션의 Dictionary
5. RouteData의 RouteHandler 호출
   : RouteHandler에 RouteData, Http Header, Cookie, Auth, Query string, post data를 포함한 모든 HttpContextBase전달

* Route Entry의 순서는 매우 중요하다. System.Web.Routing.RouteTable.Routes는 정렬된 목록이 제공되며,
  이는 Global.asxs 파일안에 정의되어있는 순서대로 구성이 되게 된다. 보다 명확한 매치에 해당되는 Route를
  먼저 등록시켜야지 된다.

* Server의 HDD에 있는 경우에는 언제나 그 정적인 파일이 우선적으로 호출된다. Routing 구성 설정보다
  우선권을 갖게 된다.


기본 Routing 작성

Route defaultRoute = new Route("{controller}/{action}/{id}", new MvcRouteHandler())
{                
    Defaults = new RouteValueDictionary(new { controller = "Home", action = "index", id = "" })
};
routes.Add("default", defaultRoute);

routes.Add(new Route("Catalog/{color}", new MvcRouteHandler())
{
    Defaults = new RouteValueDictionary(
        new { controller = "Products", action = "List", color=(string)null }
        )                
});

제약사항이 있는 Routing 작성
: Constraint를 이용. 제약 사항을 추가적으로 만들어주기 위해서는 System.Web.Routing.IRouteConstraint를
  상속받는 Class를 제공해서 RouteValueDictionary에 넣어주면 된다.

routes.Add(new Route("Article/{id}", new MvcRouteHandler())
{
    Defaults = new RouteValueDictionary(new { controller = "Articles", action = "Show" }),
    Constraints = new RouteValueDictionary(
            new
            {
                id = @"\d{1,6}", //ID 값이 항시 정규표현식 안에 일치하는지 제약조건 강제화.
                httpMethod = new HttpMethodConstraint("GET"), //항시 GET method로만 call이 가능
                userAgent = new UserAgentConstraint("iPhone") //iPhone web agent로만 접근 가능 
            }
        )
});

public class UserAgentConstraint : IRouteConstraint
{
    private string _requestSubString;
    public UserAgentConstraint(string requestSubString)
    {
        _requestSubString = requestSubString;
    }

    #region IRouteConstraint Members

    public bool Match(HttpContextBase httpContext, Route route, string parameterName, RouteValueDictionary values, RouteDirection routeDirection)
    {
        if(httpContext.Request.UserAgent == null)
            return false;
        return httpContext.Request.UserAgent.Contains(_requestSubString);
    }

    #endregion
}

* 현재 사용의 매개변수는 재사용될 수 있다는 점을 염두해둬야지 된다.이 때 고려될 것은 매개변수보다
  앞쪽에 나오는 매개변수에 대한 값들만이 재사용된다.
  routes.MapRoute(null, "{controller}/{action}/{color}/{page}");  의 경우에,
  <%=Html.ActionLink("ClickMe", "List", "Catalog", new {page=789}, null)%>로 구성이 될 경우에는 color
  값은 ActionLink가 호출이 되는 현재 요청의 color 값이 사용이 된다. 그러나,
  <%=Html.ActionLink("ClickMe", "List", "Catalog", new {color="black"},null%>로 구성이 될 경우에는
  page값이 재사용되지 못하고 route entry는 일치되지 못한다.

Mockup class를 이용한 Routing test code
URL 테스트는 Rest 및 개발에서 가장 중요한 사항중 하나인데. 테스트코드보다 직접 실행해서 한번 테스트해보는 경우가 더 많은 것 같다.;

private string GetOutboundUrl(object routeValues)
{
    // Get route configuration and mock request context
    RouteCollection routes = new RouteCollection();
    MvcApplication.RegisterRoutes(routes);
    var mockHttpContext = new Moq.Mock();
    var mockRequest = new Moq.Mock();
    var fakeResponse = new FakeResponse();
    mockHttpContext.Setup(x => x.Request).Returns(mockRequest.Object);
    mockHttpContext.Setup(x => x.Response).Returns(fakeResponse);
    mockRequest.Setup(x => x.ApplicationPath).Returns("/");
    // Generate the outbound URL
    var ctx = new RequestContext(mockHttpContext.Object, new RouteData());
    return routes.GetVirtualPath(ctx, new RouteValueDictionary(routeValues)).VirtualPath;
}

이 code를 이용한 test code는 다음과 같이 적을 수 있다.

[Test]
public void Football_Page1_Is_At_Slash_Football()
{
    Assert.AreEqual("/Football", GetOutboundUrl(new
    {
        controller = "Product",
        action = "List",
        category = "Football",
        page = 1
    }));
}

URL의 테스트가 꼭 필요하긴 한데.. 요즘들어 일을 이런쪽으로 전혀 안하고 있다는 아쉬움이 많이 들고 있는듯.;

이번에 ASP .NET 사이트에서 발표된 Chart control의 경우에는 지금까지 있었던 상용 Chart들을 완전히 뒤집어버릴 수준의 control을 제시하고 있다. 일반 2D Chart에서 3D Chart까지 거의 안되는 Chart가 없을 정도로 많은 표현을 제공하고 있는데, 한 3년전까지만 해도 chart 만드는 것때문에 엄청나게 고생하던 것을 생각하면 참 여러가지로 많은 생각이 들게 된다. (그때 만든 Chart DLL을 생각하면 눈물이 앞을.. T_T)

일주일에 두번이상은 가는 asp.net 에서 배신을 당했다. ㅋㅋ 

ASP .NET MVC Framework가 1월 27일부로 RC 버젼이 나왔다. 

ActionResult의 Type중 ContentResult를 이용한다. 

MVC Model은 매우 멋진 Web Model이고, View에서 표현하는 방법이 표준 Html을 기본적으로 사용하고 있기 때문에 매우 만족스러울 뿐 아니라, 디자이너와의 협업에서 뛰어난 적응도를 보여준다.

기존의 ASP .NET에서는 수 많은 서버 control들이 있었고, 이러한 서버 control들은 각각의 사용법 및 세부적인 디자인을 변경시키는 데에 있어서 많은 어려움을 가지고 있었던 것이 사실이다. (내가 잘 못하는 것도 있겠지만. –-;;)

MVC 모델을 사용하다가 자주 만드는 것 중 하나가 table인데, 각각의 데이터에 따라서 매번 다른 table을 반복작업을 하는 것이 싫어서 하나의 MVC user control을 만들었다.

먼저 LINQ를 이용한 데이터의 pagination을 제공하고, table에 각각 필요한 데이터를 Model로 선언한다. 그리고 table의 pagination은 AJAX call을 기반으로 한다. 

LINQ를 이용한 PagedList :