标签: onion-architecture

我试图将NHibernate从我的服务层分离出来.我的架构看起来像这样:

web - > services - > repositories - > nhibernate - > db

我希望能够从我的服务层和可能的我的web层产生nhibernate查询,而不知道那些层知道他们正在处理什么样的orm.目前,我在我的所有存储库中都有一个find方法IList<object[]> criteria.这允许我传递一个标准列表,例如new object() {"Username", usernameVariable};从我的架构中的任何地方.NHibernate接受它并创建一个新的Criteria对象并添加传入的标准.这适用于我的服务层的基本搜索,但我希望能够传入我的存储库转换为NHibernate Criteria的查询对象.

真的,我很乐意实现类似于这个问题所描述的内容:抽象nhibernate标准是否有价值.我只是没有找到任何关于如何实现这样的东西的好资源.该问题中描述的方法是一种好方法吗？如果是这样,有人可以提供一些关于如何实施这样的解决方案的指示吗？

我开始设计一个具有域驱动设计和洋葱架构的控制台应用程序,在此之前,我想探索一个完全设计的应用程序,具有域驱动设计和洋葱架构.如果您遇到任何类型的样品,请将链接发布到它.

我正在建设一个新项目.

我有一个名为"bootstrapper"的独立项目,它包含IOC和WebActivator.我的问题是包含WebActivator的类甚至没有在调试中加载!可能是我错过了什么？

[assembly: WebActivatorEx.PreApplicationStartMethod(typeof(IocConfig), "RegisterDependencies")]
 public class IocConfig
 {
        public static void RegisterDependencies()
        {
            //..........
        }
 }

我有一个接口IApplicationConfig，它基本上包含ConnectionStrings，例如数据库，Blob存储和其他内容。对于我的解决方案中的每个“可执行”项目，例如网站，命令行工具等，都有该接口的具体实现，该接口配置为通过依赖项注入来解决。

我的问题是，我应该将这些IApplicationConfig实施放在哪里？

在每个“可执行”项目中，我web.config/ 旁边app.config？或者在基础设施，如Project1Config.cs，Project2Config.cs等？

我正在尝试配置我的Object Mapper而不知道我正在使用哪个mapper.:/

这可能听起来有点奇怪.这样做的原因是我正在尝试使用洋葱架构,因此我的UI无法了解我的基础架构中的Object Mapper.请参阅此解决方案以获取示例.

我在弄清楚如何"委托"无默认映射行为时遇到了一些麻烦.像:

Mapper
    .CreateMap<MyModel, MyDestViewModel>()
    .ForMember(
        dest => dest.SomeDestinationProperty,
        opt => opt.MapFrom(src => src.SomeSourceProperty)
    );

我在我的MVC项目中设置了一个从Global.asax调用的类,这是我想要配置映射的地方.

public static class MapConfig
{
    public static void RegisterMaps()
    {

    }
}

我以为我可以做以下事情.(IMapper是位于Domain中的自定义接口)

public static void RegisterMaps(HttpConfiguration config)
{
    var mapper = config.DependencyResolver.GetService(IMapper);
    mapper.CreateMap<MyModel, MyViewModel>();
}

现在......我将如何设置像.ForMember这样的特殊行为？请记住,它不能是AutoMapper特定的.

我正在思考这些方面的事情,mapper.CreateMap<MyModel, MyViewModel>(Expression<Func<T>>)其中Func会做一些我现在无法弄清楚的黑魔法:( - 我是在正确的道路上还是我错过了一些必要的东西？

Onion 架构提供的主要优势之一是能够交换“基础设施”元素，例如“数据访问、I/O 和 Web 服务”( http://jeffreypalermo.com/blog/the-onion-architecture ) -第3部分/）。

Jeff 在 2008 年的帖子中表示，“业界至少每三年就会修改一次数据访问技术”。

有没有人有一个相当大的项目的例子，其中使用了洋葱架构并随后更换了关键基础设施元素？

我有兴趣了解：

• 一般来说，这种情况有多常见？

我的直觉告诉我，虽然“数据访问技术”可能每三年修改一次，但对运行解决方案的实际基础设施进行更改（这将使实现这一好处）的频率可能要低得多？

• 该解决方案最初运行的条件是什么？
• 是什么导致了底层基础设施的变化？
• 关于以这种方式改变基础设施的实际影响是否可以吸取教训，这可能使我们能够改进洋葱架构的原始实现？

我很想知道除了更换基础设施组件和实现相同的接口之外是否还需要进行意外的更改。例如，当从关系数据库模型迁移到 NoSQL DB 模型时，新基础设施是否需要将新参数传递给先前定义的方法，例如 SaveOrder(int ID) -> SaveOrder(int ID, bool AllowSiblings, bool SiblingCreated)。

• 与传统的耦合方法相比，这种架构的实施+重新设计以迁移到新的基础设施是否显着减少了所需的总工作量？

• 开发人员是否发现耦合的、硬引用的代码比松散耦合的、间接引用的代码更容易编写和调试，但基础设施更改的最终回报使这值得吗？

我正在使用 ASP.NET MVC 和Onion Architecture创建一个 Intranet 网站。我一直在实施存储库模式，但我遇到了困难。

假设我有一个包含 IDDocument 的 Document 表。然后这是我的回购（只有一种方法）：

class Repository<T> : IRepository<T> where T : class
{
    private readonly PrincipalServerContext context;
    private DbSet<T> entities;
    //Constructor and stuff here
    public T Get(long id)
    {
        return entities.SingleOrDefault(s => s.IDDocument == id);//Here is my problem
    }
}

问题是我不能使用它，因为 T 未被识别为来自 Document 表。解决方案是创建一个 BaseEntity：

public class BaseEntity{
  public int ID{get;set;}
}

然后我的文档 POCO 变为：

public class Document : BaseEntity{ 
   //Properties here
}

还有我的回购：

 class Repository<T> : IRepository<T> where …

最近我发现以下方法对我参与的许多项目都很有效。然而，问题是，我读到 ef core DbContext 本身就是一个 UoW，我不应该创建自己的 UoW 和存储库。但在这种情况下，我无法从应用程序逻辑层中抽象出持久层。

TL;DR 问题是： 是否有可能既不拥有自己的存储库也不拥有 UoW，并且仍然遵循上述架构，并将 DbContext 作为 UoW？

我的架构如下：

第 1 层（最内部）：聚合、实体、POCO 域类、值对象

第 2 层： 域服务

第 3 层： 应用程序服务（CQRS 命令、查询、处理程序）和存储库接口

第 4A 层：（持久层）存储库实现（此处注入 DbContext）EF Core 映射（ORM 映射）

第 4B 层： Asp MVC API（此处注册 DI）

API 的控制器只是发出命令和查询（通过 MediatR）。

上述方法的优点是应用程序核心（第 1、2 和 3 层）完全从持久性中抽象出来。缺点是您确实必须编写自己的存储库。

这是正确的方法吗？或者我错过了什么？

我开始使用洋葱架构，因为我对以前的项目结构不满意。我的主要问题是，我可以从数据访问层返回 DTO 吗？

这是我当前的结构：

/Core
 - Application
 - Domain
/Infrastructure
 - Persistence
 - Identity
/WebApi
 - WebApi

快速解释：

• 应用程序层是我所有业务逻辑的地方
• 领域层是定义所有实体/模型的地方
• 持久层是我查询数据库的地方
• 身份层用于用户管理
• WebApi 层是我拥有控制器的地方

数据流程如下：

Client <- WebApi Layer <- (DTO) Application Layer <- (Entity) Persistence Layer

截至目前，持久层返回在域层中定义的实际数据库实体，应用程序层将其转换为 DTO。

我的问题是，持久层实际上经常需要执行不同的查询，这将使类型与实体类型不同。例如，我可以连接不同的表、应用分组等。因此，我无法返回实体类型。

我是否可以从持久层（数据访问层）返回 DTO？如果是，我在哪里定义这些 DTO？将它们与应用程序层中的其他 DTO 一起定义并在持久层中使用这些 DTO 会使其依赖于应用程序层（我认为这不是很好，因为我们希望最大限度地减少耦合）。另一种选择是在域层中与实体一起创建它们（可能是更好的方法）？为了保持一致性，我应该只从应用程序层返回 DTO，还是可以同时返回实体类型和 DTO？

很多问题我都找不到。只是想成为一名更好的程序员:)

DDD 的领导者将应用层视为事务管理的适当位置。例如，来自文斯·沃恩：

应用程序服务驻留在应用程序层。[...]。他们可以控制持久性事务[...]”。

这是否不会将基础设施问题泄漏到应用程序层中，因为持久性（更具体地说，其实现细节）不是应用程序层应该意识到的事情？

虽然我可以在应用程序层中定义一个契约来满足基础设施层的具体要求，但这仍然感觉有点像泄漏实现细节。虽然这确实实现了与实际持久性具体的解耦，但我认为它并不会使应用程序层真正忽略持久性实现细节。这难道不是我应该关心的事情吗？

下面是一个伪 PHP 的示例，展示了它的外观：

namespace Acme\Application\Contracts;

// A contract in the Application Layer to be satisfied by an infrastructure implementation
interface TransactionManager {
    public function begin() : void;
    public function commit() : void;
    public function rollBack() : void;
}

namespace Acme\Intrastructure\PDO;

class PDOTransactionManager implements TransactionManager {
   private PDO $pdo;

   public function begin() : void {
      $this->pdo->beginTransaction();
   }

   // ...
}

namespace Acme\Application\Modules\Ordering;

// A context agnostic application service
final …