开发者

Is it correct to have references to repositories in facades

开发者 https://www.devze.com 2023-01-24 05:20 出处:网络
Or should I always get my entities via service methods? Th开发者_开发知识库anksMost of the time I try to separate my layers as much as possible.Usually I\'ll have my services act as facades to the bu

Or should I always get my entities via service methods?

Th开发者_开发知识库anks


Most of the time I try to separate my layers as much as possible. Usually I'll have my services act as facades to the business logic. Within business logic I use a DI Container, like Unity, to resolve my repositories...

Example:

IUnityContainer container = IoCManager.Container;
using (var repository = container.Resolve<IRepository<Token>>())
{
    return repository.Eagerly(f => f.Fetch<TokenSetting>(t => t.Settings))
                     .Where(t => t.Value == tokenGuid && t.Expired == null)
                     .FirstOrDefault();
}

My business logic contains no dependencies now on my infrastructure layer (repositories). For a great Repository implementation take a look at NCommon. Ritesh Rao wrote some great examples of pattern usage for DDD.

Whether it's wrong to reference your repositories is subjective. I think DDD purists will tell you it most likely is. "How much SoC are you trying to achieve" is the real question. It's usually best to strive for high cohesion via loose coupling, but sometimes that can be overkill.

Hope this helps.


[EDITED]

Repositories can exist within the domain. Really they sit in between your business logic / model and your infrastructure model. You are correct to depend on the interface not implementation.

Look at Martin Fowler's - Separated Interface Pattern. In my above example I depend on the interface. The DI container resolves the actual implementation of my concrete repository class. Here is a sample DDD diagram I've been refining as I learn.

Is it correct to have references to repositories in facades

0

精彩评论

暂无评论...
验证码 换一张
取 消