标签: onion-architecture

我正在开发一个遵循洋葱架构的ASP.NET MVC项目.我在我的核心项目中添加了模型,这些模型将被称为基础结构项目中的实体框架模型的POCO类.

我的问题是如何添加依赖于实体框架的数据注释？

我可以将核心模型作为接口并在基础结构项目中继承它并进行实际实现吗？

我正在实现一个存储库模式.我的主要原因是:

• 从持久性细节中抽象客户端代码(实体框架)
• 支持可测试性

通用存储库与否？

我遇到的问题是我是否应该有一个通用的存储库.一种IQueryable<T> Query()方法将为调用代码提供构造特定查询的手段.这里的问题是这是漏洞抽象 - 实体框架细节现在泄漏到我的客户端代码中.

• 这种影响单元测试怎么样？ 我还能ICustomerRepository用这个实现模拟吗？

• 这种效果如何影响我的持久层？像Azure存储表或NHibernate.

否则我将不得不实现非常具体的查询方法ICustomerRepository,例如GetIsActiveByFirstName()和GetIsActiveByDistrict().我不喜欢这个,因为我的存储库类将变得拥挤不同的查询方法.该系统有数百种型号,因此可以有数百甚至数千种这样的方法来编写和维护.

我正在尝试遵循洋葱架构来获取在OWIN/Katana上托管的WebAPI服务.

我有这样的解决方案结构:

• DependencyResolution:包含OWIN Startup类和IoC设置
• WebApi:Web API控制器
• 基础设施:接口实施
• 核心:接口

我希望DependencyResolution项目为WebApi项目注入依赖项.DependencyResolution确实有一个构建任务输出到WebApi项目的输出文件夹.

我正在遵循这里概述的方法,使用Autofac和DotNetDoodle.Owin.Dependencies NuGet包:

http://www.tugberkugurlu.com/archive/owin-dependencies--an-ioc-container-adapter-into-owin-pipeline

但是,在我的Startup类中注册服务时,对RegisterApiControllers()的调用将失败.DepenedencyResolution程序集将是第一个执行,因此它将无法获取包含ApiContollers(WebAPI程序集)的程序集:

public IContainer RegisterServices()
{
    ContainerBuilder builder = new ContainerBuilder();

    builder.RegisterApiControllers(Assembly.GetExecutingAssembly());
    builder.RegisterType<MyRepo>()
           .As<IRepo>()
           .InstancePerLifetimeScope();

    return builder.Build();
}

使用Assembly.Load()是唯一可行的选择,或者我应该放弃保持DependencyResolution项目被隔离的想法,只是从WebApi项目中引用它(看起来有点不那么洋葱)？

我正在努力学习洋葱架构,据我所知,我已经按如下方式组织了我的解决方案:

域

• Domain.Entities(业务对象)
• Domain.Interfaces(域服务和存储库的接口)
• Domain.Services(域服务接口的实现)

基础设施

• Infrastructure.Data(使用EF实现存储库和工作单元)
• Infrastructure.DependencyResolution(使用Unity实现IoC)

UI

• UI.WebMVC

以下是我的问题:

1-我对这些层是对的还是我错过了什么？

2-对于与特定技术(例如,日志记录)相关的服务,其接口应该是(Domain.Interfaces或Infrastructure.Interfaces)？

3-据我所知,域名服务将处理我的业务用例,以便从应用程序服务中获得哪些好处

4-域服务和应用服务之间有什么区别,应用服务接口应该在哪个项目中？

5-用户授权过程应该是应用服务或域服务的一部分吗？

我正在挖掘如何构建项目,所以我偶然发现了Onion Architecture.据我了解,它更像是一个以域为中心的焦点架构,而不是数据库驱动的类型.

我正在寻找一些github项目来研究和了解有关该架构的更多信息,所以我找到了这个项目https://github.com/chetanvihite/OnionArchitecture.Sample

我很难理解:

namespace Domain.Interfaces
{
    public interface IUserRepository
    {
        IEnumerable<User> GetUsers();
    }
}

namespace Services.Interfaces
{
    public interface IUserService
    {
        IEnumerable<User> GetUsers();
    }
}

namespace Services
{
    public class UserService : IUserService
    {
        private readonly IUserRepository _repository;

        public UserService(IUserRepository repository)
        {
            _repository = repository;
        }

        public IEnumerable<User> GetUsers()
        {
            return _repository.GetUsers();
        }
    }
}

他如何使用它是通过构造函数注入.

private readonly IUserService _service;

public HomeController(IUserService service)
{
  _service = service;
}

1. 您是否总是将服务暴露给IUserService消费它的应用程序？但我注意到,IUserRepository有相同的方法IUserService吗？

2. 如果您说基础设施问题,它是否意味着或涉及数据库？或者不一定？如果没有,基础设施问题的例子是什么？

3. 您对免费项目/ github项目有什么建议吗？我可以下载这些项目以进一步学习或研究洋葱建筑吗？我对例子的了解更多 …

我正在将一个"大球泥"(BBOM)式系统迁移到基于域驱动设计思想的系统.

在重构的各种迭代之后,域聚合/实体当前使用内部状态对象建模,如本文中Vaughn Vernon所描述的,例如:https://vaughnvernon.co/？p = 889#comment-1896

所以基本上,实体可能看起来像这样:

public class Customer
{
    private readonly CustomerState state;

    public Customer(CustomerState state)
    {
        this.state = state;
    }

    public Customer()
    {
        this.state = new CustomerState();
    }

    public string CustomerName => this.state.CustomerName;

    [...]
}

截至今天,该系统中的状态对象始终是来自当前使用的应用程序的专有数据访问框架的数据库表包装器,其类似于活动记录模式.因此,所有状态对象都从数据访问框架的基类部分继承.目前,无法将POCO用作状态对象,实体框架或其中任何一种.

该应用程序目前使用经典的层架构,其中基础结构(包括提到的表包装器/状态对象)位于底部,然后是域.域知道基础结构,并且使用基础结构在域中实现存储库.正如您在上面所看到的,大多数实体都包含一个公共构造函数,用于在域内方便地创建新实例,内部只是创建一个新的状态对象(因为域知道它).

现在,我们希望进一步发展这个并逐渐转变架构,从而产生更多的"洋葱"式架构.在该体系结构中,域只包含存储库接口,实际的实现将由位于其上的基础结构层提供.在这种情况下,域无法再知道实际的状态对象/数据库表包装器.

解决这个问题的一个想法是让状态对象实现域定义的接口,这实际上似乎是一个很好的解决方案.它在技术上也是可行的,因为即使状态对象必须从特殊的数据访问基类继承,它们也可以自由地实现接口.所以上面的例子将改为:

public class Customer
{
    private readonly ICustomerState state;

    public Customer(ICustomerState state)
    {
        this.state = state;
    }

    public Customer()
    {
        this.state= <<<-- what to do here??;
    }

    [...]
}

因此,当存储库(现在在基础结构中实现)实例化一个新的Customer时,它可以轻松地传入实现ICustomerState的数据库包装器对象.到现在为止还挺好

但是,在域中创建新实体时,不再可能创建内部状态对象,因为我们不再知道它的实际实现.

有几种可能的解决方案,但它们似乎都没有吸引力:

• 我们总是可以使用抽象工厂来创建新实体,然后这些工厂将由基础设施实施.虽然在某些情况下,由于实体的复杂性,域工厂是合适的,但我不希望在每种情况下都使用一个,因为它们会导致域中的大量混乱,并且还会传递另一个依赖项. .
• 我们可以使用另一个类(POCO)来保存值,然后通过基础结构从/向数据库包装器进行转换,而不是直接使用数据库表包装器作为状态对象.这可能会起作用,但最终会产生大量额外的映射代码,并导致每个数据库表(DB包装器,状态对象,域实体)有3个或更多类,这使得维护变得复杂.如果可能的话,我们希望避免这种情况.
• 为了避免在工厂周围传递,实体内部的构造函数可以调用一些类似于单一的魔术StateFactory.Instance.Create<TState>() …

我最近在阅读有关域驱动设计（DDD）的文章，我喜欢这个概念，尤其是Onion体系结构的构想（https://www.youtube.com/watch?v=pL9XeNjy_z4）。

我很想知道我们如何使用Django Rest Framework实现这种架构，或者换句话说，我们可以使用Onion arch风格的Django rest框架进行DDD吗？

1. 是否可以将洋葱架构中的概念映射到DRF？
2. 当像Apache isis（https://isis.apache.org/）之类的框架通过构建面向对象的UI来进行DDD时，用户可以直接与域实体进行交互，DRF可能怎么做？

作为示例，我以以下方式编写DRF代码：

在models.py中，我将定义模型：

class Library(models.Model):
    library_id = models.AutoField(primary_key=True)
    name = models.CharField(max_length=30)
    ...

    #This helps to print in admin interface
    def __str__(self):
        return u"%s" % (self.name)

在serializers.py中，我将使用模型序列化器：

class LibrarySerializer(serializers.ModelSerializer):
    class Meta:
        model = Library
        fields = '__all__'

我将在urls.py中有相应的url：

router.register(r'libraries', LibraryViewSet)

并在views.py中执行CRUD操作：

class LibraryViewSet(viewsets.ModelViewSet):
    queryset = Library.objects.all()
    serializer_class = LibrarySerializer

这与DDD / Onion体系结构有什么关系（可能进行了适当的修改）？

我目前正在使用洋葱架构设置 Visual Studio 解决方案。我对如何构建解决方案有很好的理解，但我遇到了一些麻烦。我的解决方案正在使用多个 API。这些 API 使用 WCF、Soap Web 服务和 RESTSharp for REST 服务使用。我不确定如何构建它。

最大的困惑是围绕 REST 服务，因为这不仅使用 RESTSharp，还使用一些用于序列化的 POCO 类。我也有：

ApiResult<T> where T is any of the POCO classes.

我的第一个想法是创建 Infrastructure.RestSharp，我将在其中实现所有都返回 ApiResult 的接口，但问题是我将这些 POCO 类和 ApiResult 放在哪里？由于接口正在使用它们，它们将不得不进入 Core 中的某个地方，但是将它们放在哪里比较合适？

WCF 和肥皂服务怎么样？我会创建一个 Infrastructure.WebServices 吗？

我正在制作一个基于 .Net 的应用程序的结构。目前，我使用的是 MVC 5。以下是系统不同组件的详细信息。\n
1. 数据库\xe2\x80\x93 这是底层数据库，将包含数据\n
2. OData API \xe2\x80\ x93 此 API 将与数据库交互，并且仅执行与数据库相关的操作 (CRUD)。我希望这个 API 成为访问和操作数据的唯一平台。它将提供通过不同方式（IQueryable、SQL 查询、存储过程）检索数据的功能。\n
3. 业务服务\xe2\x80\x93 它由两部分组成。引擎和API。引擎中将包含业务逻辑，其中可能包括业务规则，例如 WorkflowEngine 将处理所有工作流操作。驻留工作流程操作（CRUD 操作）和非常驻工作流程操作（提交、批准、发回）。API将在UI和引擎之间进行通信。然后引擎将运行业务逻辑并与 OData 进行通信。BusinessAPI 将是专有 API，对这些 API 的访问将基于订阅（付费访问）。\n
4. UI \xe2\x80\x93 用户界面将基于 MVC，仅与业务 API 交互，并且仅负责显示数据并将数据发送回 BusinessAPI。
\n

它看起来像一个 N 层架构。如果我引入接口，它是否可以与ONION架构相媲美。\n
如何将其转换为 ONION 架构而不影响安全性、可扩展性和性能。\n

根据 DDD 或六边形架构记录的推荐实践 - 域模型应该与与实际使用的技术（表/列名称、联接等、JPA 注释）更相关的数据模型表示分离。这里的一个实际问题是——如何在这个模型中进行诸如乐观版本控制之类的事情？假设您有一个域服务，可以在域模型上读取-->更新-->保存。现在，JPA 实体可能有一个无法向上传递的版本列。因此，当保存调用到达存储库并且存储库本质上再次进行（模型->实体）转换和读取+更新时，它将无法判断最初读取的是实体的哪个版本。
第二个问题是对此的性能考虑，涉及这里的一些额外阅读