Programming is Fun

Domain-Driven Model의 구현에 있어서, Repository와 Service를 각기 달리 구현하는 것은 매우 중요한 문제이다.
Service를 구현한 Repository가 변경되어도 언제나 동일한 서비스가 구현이 가능해야지 되며, 이는 데이터의 저장소나 서비스의 구현을
달리 나눈다는 점에서 테스트의 유용성에도 많은 영향을 미치게 된다. 무엇보다 이 둘이 결합되어 있으면 테스트를 행하는 것이 거의 불가능하다.

테스트를 어떻게 하면 좋게 할 수 있을지에 대한 꽤나 좋은 솔루션으로 castle을 찾게 되었다.

castle은 web.config나 xml 파일로 지정된 component를 기반으로 그 프로젝트에서 사용될 service를 정의하고, 제공해주는 역활을 하고 있으며,
이를 이용해서 단순히 config 파일만 변경하는 것으로 각기 다른 Repository가 제공되는 프로젝트를 만드는 것이 가능하다.

예를 들어 Interface가 다음과 같이 정의된 Repository들이 있을 때에,

namespace DomainModel.Abstract
{
    public interface IProductRepository
    {
        IQueryable Products { get; }
    }
    public interface IShippingDetailRepository
    {
        IQueryable ShippingDetails { get;}
        bool AddShippingDetail(ShippingDetail shippingDetail);
    }
}

이를 이용한 Service Repository는 castle에서 다음과 같이 선언될 수 있다.

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

위와 같은 Domain-Driven model에서는 가장 중요한 것이 서비스와 데이터간의 완벽한 분리이다.
어떤 식으로 구현해주는 것이 좋은지에 대해서 좀더 많은 생각과 좀더 많은 공부가 필요하다. -_-;;

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

Model 객체의 경우에는 데이터의 Display class로만 주로 사용하고 있었는데. 재미있는 특징들이 이제서야 많이 보이는 것 같다.

특히 IDataError interface의 상속으로 View에서의 데이터 에러를 검증하고, 그 에러를 View에서 표시하는데 사용할 수 있는 여력이 많이 보인다.
여러가지로 재미있다고 해야지 될까나.

public class GuestResponse : IDataErrorInfo
{
    public string Name { get; set; }
    public string Email { get; set; }
    public string Phone { get; set; }
    public bool? WillAttend { get; set; }
    public string Error { get { return null; } } // Not required for this example
    public string this[string propName]
   {
       get {
               if((propName == "Name") && string.IsNullOrEmpty(Name))
                    return "Please enter your name";
               if ((propName == "Email") && !Regex.IsMatch(Email, ".+\\@.+\\..+"))
                    return "Please enter a valid email address";
               if ((propName == "Phone") && string.IsNullOrEmpty(Phone))
                    return "Please enter your phone number";
               if ((propName == "WillAttend") && !WillAttend.HasValue)
                    return "Please specify whether you'll attend";
               return null;
             }
    }
}

참 여러가지로 사용되는 Interface가 많은 것 같다. 무언가 class를 생성할 때, 언제나 먼저 생각해줄 것이.
일단 Framework에서 지원되는 class가 있는지. 내가 사용할 action이 정의되어있는 interface는 존재하는지에 대한
생각은 항시 필요한 것 같다.

공부할 내용이 너무나 많아. --;

그리고, asp.net에서 SmtpClient를 사용할 때, 개발 환경이나 개인 환경에서 SMTP 서버를 사용할 수 없을 때, File에 지정할 수 있는 방법이 있다
web.config에 다음과 같은 설정을 넣어주면 된다.