잊지 않겠습니다.

'Castle'에 해당되는 글 2건

  1. 2010.01.07 Windsor를 이용한 n-Tier MVC 개발
  2. 2009.12.27 Castle IoC Component

Windsor를 이용한 n-Tier MVC 개발

.NET Framework 2010. 1. 7. 01:18
DomainModel은 모두다 구성이 마쳐진 상태로 가정하고 MVC에 구성하는 방법에 대해서 알아본다.

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


view source
print?
01.    <configsections>
02.        <section name="castle" type="Castle.Windsor.Configuration.AppDomain.CastleSectionHandler, Castle.Windsor">
03.    </section>
04.    <castle>
05.        <components>
06.            <component id="productRepository" service="DomainModel.Abstract.IProductRepository, DomainModel" type="DomainModel.Concrete.SqlProductRepository, DomainModel" lifestyle="PerWebRequest">
07.                <parameters>
08.                    <connectionstring>Data Source=HOME-PC\SQLEXPRESS;Initial Catalog=SportsStore;Integrated Security=True;Pooling=False</connectionstring>
09.                </parameters>
10.            </component>
11.        </components>
12.    </castle>
13. 
14.    <httpmodules>
15.      <add name="PerRequestLifestyle" type="Castle.MicroKernel.Lifestyle.PerWebRequestLifestyleModule, Castle.MicroKernel">
16.    </add>
17.</httpmodules></configsections>

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

view source
print?
01.public class WindsorControllerFactory : DefaultControllerFactory
02.{
03.    private WindsorContainer container;
04. 
05.    public WindsorControllerFactory()
06.    {
07.        container = new WindsorContainer(new XmlInterpreter(new ConfigResource("castle")));
08.        var controllerTypes = from t in Assembly.GetExecutingAssembly().GetTypes()
09.                              where typeof(IController).IsAssignableFrom(t) select t;
10.        foreach(Type t in controllerTypes)
11.        {
12.            container.AddComponentWithLifestyle(t.FullName, t, LifestyleType.Transient);
13.        }
14.    }
15. 
16.    protected override IController GetControllerInstance(System.Web.Routing.RequestContext requestContext, Type controllerType)
17.    {
18.        return (IController)container.Resolve(controllerType);
19.    }
20.}
마지막으로 Controller의 생성자를 이용해서 사용될 DomainModel의 interface를 등록하는 것으로 완료할 수 있다.
view source
print?
01.public class ProductController : Controller
02.{
03.    private IProductRepository _productRepository;
04.    public ProductController(IProductRepository productRepository)
05.    {
06.        _productRepository = productRepository;
07.    }
08. 
09. 
10.    public ViewResult List()
11.    {
12.        return View(_productRepository.Products.ToList());
13.    }
14.}

상당히 간단한데 왜 외워지지가 않는 것일까.; Castle에 대해서는 두번째 포스트인데 포스트 내용이 비스무리하다. -_-
저작자표시 비영리 변경금지
Posted by Y2K
,

Castle IoC Component

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

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

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

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

view source
print?
01.namespace DomainModel.Abstract
02.{
03.    public interface IProductRepository
04.    {
05.        IQueryable<product> Products { get; }
06.    }
07.    public interface IShippingDetailRepository
08.    {
09.        IQueryable<shippingdetail> ShippingDetails { get;}
10.        bool AddShippingDetail(ShippingDetail shippingDetail);
11.    }
12.}
13.</shippingdetail></product>

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

view source
print?
01.<castle>
02.    <components>
03.        <component id="productRepository" service="DomainModel.Abstract.IProductRepository, DomainModel" type="DomainModel.Concrete.SqlProductRepository, DomainModel" lifestyle="PerWebRequest">
04.            <parameters>
05.                <connectionstring>Data Source=HOME-PC\SQLEXPRESS;Initial Catalog=SportsStore;Integrated Security=True;Pooling=False</connectionstring>
06.            </parameters>
07.        </component>
08.  <component id="orderSubmitter" service="DomainModel.Services.IOrderSubmitter, DomainModel" type="DomainModel.Services.FakeOrderSubmitter, DomainModel" lifestyle="PerWebRequest">
09.    <parameters>
10.  </parameters></component>
11.  <component id="shippingDetailRepository" service="DomainModel.Abstract.IShippingDetailRepository, DomainModel" type="DomainModel.Concrete.SqlShippingDetailRepository, DomainModel" lifestyle="PerWebRequest">
12.    <parameters>
13.      <connectionstring>Data Source=HOME-PC\SQLEXPRESS;Initial Catalog=SportsStore;Integrated Security=True;Pooling=False</connectionstring>
14.    </parameters>
15.  </component>
16.        <!--<component id="fackProductRepository"
17.       service="DomainModel.Abstract.IProductRepository, DomainModel"
18.       type="DomainModel.Concrete.FakeProductRepository, DomainModel">
19.    <parameters/>
20.  </component>-->
21.    </components>
22.</castle>

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

티스토리툴바