标签: onion-architecture

我的存储库处理并为丰富的域模型提供持久性.我不想将贫血的Entity Framework数据实体暴露给我的业务层,所以我需要一些在它们之间进行映射的方法.

在大多数情况下,从数据实体构造域模型实例需要使用参数化构造函数和方法(因为它很丰富).它不像属性/字段匹配那么简单.AutoMapper可用于相反的情况(映射到数据实体),但不能用于创建域模型.

以下是我的存储库模式的核心.

在EntityFrameworkRepository类的工作有两个泛型类型:

• TDomainModel:丰富的域模型
• TEntityModel:实体框架数据实体

定义了两种抽象方法:

• ToDataEntity(TDomainModel):转换为数据实体(for Add()和Update()方法)
• ToDomainModel(TEntityModel):构建域模型(用于Find()方法).

这些方法的具体实现将定义所讨论的存储库所需的映射.

public interface IRepository<T> where T : DomainModel
{
    T Find(int id);
    void Add(T item);
    void Update(T item);
}

public abstract class EntityFrameworkRepository<TDomainModel, TEntityModel> : IRepository<TDomainModel>
    where TDomainModel : DomainModel
    where TEntityModel : EntityModel
{
    public EntityFrameworkRepository(IUnitOfWork unitOfWork)
    {
        // ...
    }

    public virtual TDomainModel Find(int id)
    {
        var entity = context.Set<TEntityModel>().Find(id);

        return ToDomainModel(entity);
    }

    public virtual void …

我正在使用Jeffrey Palermo描述的Onion架构设计ASP.NET MVC应用程序.

这是一个ASP.NET MVC 2.0项目中,我要求所有的视图中使用专用的视图模型是强类型的 - 我们不会通过域模型对我们的看法.我们使用AutoMapper进行翻译 - AutoMapper在基础架构中被隔离,Web不知道或不关心AutoMapper的使用.

目前,我正在Web项目中定义IViewModelMapping接口 - 只是因为控制器将使用此服务,并且它可以直接访问自己的View模型.这样,界面可以访问域模型(在Core中)和View模型(在Web中).

为了提供IViewModelMapping接口的实际实现,我在Infrastructure项目中创建了一个ObjectMapping命名空间,它将实际的映射实现与洋葱的Intrastructure隔离开来.在这样做时,这将要求Infrastructure依赖于BOTH Core AND Web.

我的问题是:由于这两个项目在技术上都位于洋葱的郊区(在同一层中) - 是否允许一个项目依赖于该层中的另一个项目？有没有人注意到这个设计有任何潜在的陷阱？

另一种设计是将IViewMapper接口移动到Core中 - 但这是不可能的,因为Core无法访问ViewModel类.我也可以将视图模型移动到Core中,但我觉得它们不属于那里,因为它们特定于UI层.

建议的体系结构如下 - 请注意,基础结构依赖于Core和Web.Web保持隔离状态,只能访问Core业务逻辑.

http://www.matthidinger.com/images/onion-arch.png

领域驱动设计(DDD)与杰弗里巴勒莫的" 洋葱建筑 " 之间有什么关系？

我正在学习Jeffrey Palermo着名的洋葱建筑.不是特定于这种模式,但我无法清楚地看到存储库和域服务之间的分离.我(错)了解存储库涉及数据访问和服务更多关于业务层(引用一个或多个存储库).

在许多示例中,存储库似乎具有某些类似于GetAllProductsByCategoryId或的业务逻辑GetAllXXXBySomeCriteriaYYY.

对于列表,似乎服务只是存储库中的包装器而没有任何逻辑.对于层次结构(父/子/子),它几乎是同一个问题:存储库的角色是加载完整的层次结构吗？

我正在为即将到来的内部应用程序设置一个项目结构,该应用程序试验了Palermo提出的Onion Architecture(http://jeffreypalermo.com/blog/the-onion-architecture-part-3/).

我遵循他的指导方针,但到目前为止我需要对项目结构进行一些验证.

在图表之前,问题:

1. 我认为参考文献都是正确的(根据图表设置箭头表示'引用'),但有些验证会很好.

2. 我应该在依赖性解析层中添加什么？这是帮助者去的地方吗？这引用了所有其他项目？

3. Web服务和UI如何与DAL通信？(通过核心？怎么样？)

4. 应该去哪里？[我知道的广泛问题......]

简化的概念图如下(文件夹代表名称空间):

我一直在阅读洋葱建筑,今天我发现了鲍勃叔叔的清洁建筑.

对于我的生活,我看不出它们之间有任何差异,它们看起来完全相同(除了命名惯例).

这两种建筑风格有什么不同吗？如果是的话,你能解释一下吗？

干杯

您对以下"通用"代码 - 第一个洋葱风格的ASP.NET MVC架构有何看法:

这些层次解释说:

核心 - 包含域模型.例如,这是业务对象及其关系.我正在使用Entity Framework来可视化地设计实体及它们之间的关系.它让我为数据库生成一个脚本.我正在获得自动生成的类似POCO的模型,我可以在下一层(持久性)中自由引用,因为它们很简单(即它们不是特定于数据库的).

持久性 - 存储库接口和实现.基本上是对域模型的CRUD操作.

BusinessServices - 存储库周围的业务层.所有业务逻辑都应该在这里(例如GetLargestTeam(),等等).使用CRUD操作组成返回对象或获取/过滤/存储数据.应包含所有业务规则和验证.

Web(或任何其他UI) - 在这种特殊情况下,它是一个MVC应用程序,但该项目背后的想法是提供UI,由业务服务提供的驱动.UI项目使用Business层,无法直接访问Repository.MVC项目有自己的View模型,这些模型特定于每个View情境.我不是试图强制它域模型.

所以引用如下: UI - > Business Services - > Repository - > Core对象

我喜欢它:

• 我可以设计我的对象,而不是手动编码.我正在获得代码生成的Model对象.
• UI由业务层驱动/强制执行.可以针对同一商业模型对不同的UI应用程序进行编码.

关于:

• 好的,我们有一个可插拔的存储库实现,但是你有多少次真正拥有相同持久性接口的不同实现？
• UI也是如此 - 我们具有针对相同业务规则实现不同UI应用程序的技术能力,但是当我们可以简单地呈现不同的视图(移动,桌面等)时,为什么我们会这样做呢？
• 我不确定UI是否应该只通过View模型与业务层进行通信,或者我应该像现在一样使用域模型来传输数据.为了显示,我使用的是视图模型,但是对于数据传输,我使用的是Domain模型.错误？

我不喜欢的:

• Core项目现在在每个其他项目中引用 - 因为我想/必须访问Domain模型.在传统的Onion架构中,核心仅由下一层引用.
• DbContext在.Core项目中实现,因为它是由实体框架生成的,位于.edmx所在的位置.我实际上想要使用.EDMX进行可视化模型设计,但我觉得DbContext属于Persistence层,位于特定于数据库的存储库实现中.

作为一个最后的问题 - 什么是一个没有过度设计的好建筑(比如一个完整的洋葱,我们有注射,服务定位器等),但同时提供一些合理的灵活性,在你想要的地方现实需要吗？

谢谢

事先有一件事:我从N层背景到达.

我现在花了很多时间来了解洋葱建筑和相关的领域驱动概念,如六角建筑阅读资源,如Jeff Palermo的系列博客文章,Mark Seemann从DI视角的贡献,"洋葱化你的建筑",和"干净的建筑".

所有这些文章的共同之处在于它们声称有以下几点:

• 焦点围绕业务用例的域模型
• 通过强调依赖性倒置原则,在层之间进行更松散的耦合
• 提高外部基础架构的独立性,例如框架,数据持久性,UI
• 更好的可测试性/可维护性

嗯,这听起来非常好听,那些图表看起来也很甜美.但是问题出现在我身上:仅仅通过在传统的N层架构中增加外墙来实现这一切吗？

• 每个层只知道下面层的抽象
• 具体实现可以保持在每个层的内部,因此与抽象处于相同的位置
• 实现细节可以很容易地换出,因为它们是层的内部,不应该影响应用程序的其余部分

请帮助我了解以域为中心的架构的真正优势.

提前致谢!

这是我第一次实施更加以域驱动的设计方法.我决定尝试使用Onion Architecture,因为它专注于域而不是基础架构/平台/等.

为了从实体框架中抽象出来,我创建了一个带有工作单元实现的通用存储库.

该IRepository<T>和IUnitOfWork接口:

public interface IRepository<T>
{
    void Add(T item);

    void Remove(T item);

    IQueryable<T> Query();
}

public interface IUnitOfWork : IDisposable
{
    void SaveChanges();
}

实体框架的实现IRepository<T>和IUnitOfWork:

public class EntityFrameworkRepository<T> : IRepository<T> where T : class
{
    private readonly DbSet<T> dbSet;

    public EntityFrameworkRepository(IUnitOfWork unitOfWork)
    {
        var entityFrameworkUnitOfWork = unitOfWork as EntityFrameworkUnitOfWork;

        if (entityFrameworkUnitOfWork == null)
        {
            throw new ArgumentOutOfRangeException("Must be of type EntityFrameworkUnitOfWork");
        }

        dbSet = …

它们之间有什么区别(洋葱|六角形),从我的理解它们是相同的,它们关注的是应用程序核心的领域,应该是技术/框架不可知的.

它们之间有什么区别？

另外我认为使用一个优于另一个甚至是针对N层架构没有真正的优势,如果做得不好只是跟随其中任何一个都没有任何区别

使用一个优于另一个以及为什么要使用它有什么好处？什么时候用？

谢谢