问题标签 [onion-architecture]

我正在使用基于洋葱架构的这种实现的架构。我决定挑战自己，用 NLog 更改 NHibernates 默认记录器（log4net）。我了解如何配置 NLog，但在我的 LogerFactory 类中解决我的记录器的依赖项时遇到了麻烦。目前，我的 NHibernate 项目只知道我的日志接口。如何让我的 NHibernate 项目解决依赖关系？

这是我现在的程序结构：Console App 初始化 ninject 并设置我的模块，包括我的 LoggingModule 和我的 RepositoryModule。当我第一次需要我的存储库中的某些东西时，我的 SessionHelper 类会构建我的会话并配置 NHibernate。这是 NHibernate 调用我的 LoggerFactory 的地方（LoggerFactory 实现 NHibernates ILoggerFactory）。NHibernate 调用 LoggerFor(Type type); 类型作为 NHibernate.Cfg.Configuration 传入。从这里开始，我需要通过 ILoggingService 获取 NLog 的实例，这就是我感到困惑的地方。我如何在这里解决这种依赖关系？我的控制台应用程序知道分辨率，因为那是我构建内核并加载模块的地方。我只是在这里设置另一个内核吗？解决这个问题的最佳方法是什么？

编辑：这是我当前的代码：

程序.cs

记录模块.cs

存储库模块.cs

RepositoryBase.cs

SessionHelper.cs 构建 NHibernate 会话并进行配置。请注意，正在注入 connectionString。我可以在这里轻松地注入日志服务。

LoggerFactory.cs 通过 app.config 为 NHibernate 配置以用于其日志记录。这是我遇到依赖问题的地方。这与 NHibernate 并存。我可以在这里轻松地引用 NLog 并将其与 NHibernate 连接起来，但我不希望 NHibernate 关心我使用的日志记录框架。这就是为什么我只想处理我的接口并让 Ninject 注入我的具体实现。

在我当前的项目中，我越来越多地采用 DDD / Onion 架构。我仍然不清楚的许多事情之一是应该有多少封装。用一个具体的例子更容易解释。

例子

问题

对于一个实体的工厂，你，

1. 期望调用者为您构造值对象并使用它来初始化 ComplexEntity？
2. 基本上将 CLR 基本类型传递给工厂，然后构造构成实体的每个 ValueObject？

我倾向于选项 2，但我似乎无法找到支持它的文献。

编辑 1

老实说，我仍然没有更清楚。聚合根呢？

当我的实体引用其他实体时，例如下面。

1. 我应该有一个IComplexEntityFactory，ILessComplexEntityFactory？或者只是IComplexEntityAggregateFactory创建 LessComplexEntity 并实例化 ComplexEntity ？
2. 在 AggregateFactory 解决方案的情况下，如果传递给工厂的 LessComplexEntity 属性对应于现有的 LessComplexEntity，我该怎么办？我是否从存储库中检索和重用它？还是我向调用者返回错误？

3. AggregateFactory 的方法签名是什么？会不会(ValueObject a, ValueObject b)，或者(ValueObject value, LessCompelxEntity entity)

   公共类 ComplexEntity { 私有只读 int _id; 公共 int Id { 获取 { 返回 _id;} }

   }

   公共类 LessComplexEntity { 私有只读 int _id; public int Id { get {return _id;} } public ValueObject Value {get; set;} public LessComplexEntity（int id，ValuObject 值）{ } }

我正在尝试设置 NHibernate 来处理每个 Web 请求的会话。我有一个项目在使用我的任何存储库时初始化我的会话。我想知道管理每个 Web 请求的会话的最佳方式。因为我的架构是解耦的，所以我想避免在我的 Web 项目中打开会话并关闭会话。有没有一种好方法来处理这个问题，而不需要 web 项目知道 NHibernate 的存在？

这是我的请求流程：

Web 请求 -> ASP.NET MVC 3 -> 控制器 -> 服务 -> 存储库（打开会话） -> NHibernate -> 数据库 -> 返回 MVC 并退出。

我一直在使用我所说的 Service-Repository-UnitOfWork 模式编写 MVC 应用程序，它看起来像这样：

MVC Controllers --> Services --> Repositories --> EntityFramework

接着

Repositories/EntityFramework (constructs Domain Objects/POCO) --> Services --> Transform to ViewModels --> Controller --> Send the ViewModel/View to the client.

我使用 IoC 容器为服务、存储库和 UnitOfWork 配置接口，这些接口被注入到各种组件的构造函数中。

我的问题是，这和洋葱架构有什么相似之处吗？

这有任何意义吗？

我试图找出在我的架构中散列我的身份验证密码的最佳位置。这是我的请求流程：

我在服务级别的哈希与存储库级别的哈希之间纠结。我看到了两者的优势，但有人知道处理这个问题的标准地方吗？我将哈希密码存储在数据库中。

我在试图弄清楚如何解决我的架构中的依赖问题时遇到了麻烦。我正在使用 NHibernate，我试图用我自己的 ICriteriaItem 接口抽象它的 ICriteria 接口。ICriteriaItem 在我的存储库接口中使用：

ICriteriaItem.cs

IUserRepository.cs

我的服务层在其 AccountService 中使用此存储库

AccountService.cs

我的问题是使用 Ninject 获取 CriteriaItem 的实例。我所有的绑定都在我的 MVC 层中完成，目前，我的服务层对 Ninject 一无所知。我的服务已经注入到构造函数中。所以这是我的选择：

1. 我可以将 ICriteriaItem 注入到构造函数中。这感觉很脏，因为每个服务都会注入这个。我确信我可以使用基本存储库来做到这一点，但它仍然感觉很脏。

2. 注入我的内核并在我的服务中使用它来获取 ICriteriaItem 的实例。感觉更糟。

3. 只需公开 ICriteriaItem 的具体类并取消接口即可。

4. 找别的方法...

想法？我在这一切都错了吗？有没有更好的办法？我在这里想念什么？

我有几个关于洋葱架构和 MVC 的问题。

1）领域服务和应用服务有什么区别？
2) Service/Repository/UnitOfWork 模式如何适应这种架构？
3) 你认为这种架构对于 MVC 应用程序来说是一个好的计划吗？

对此的任何想法将不胜感激。

我计划为我的新应用程序遵循洋葱架构。

解决方案层次结构如下

• 域 - 定义了服务和存储库的所有接口。
• 基础设施——这是放置所有数据访问的层。这些类通常实现域中定义的接口。
• Web - 这是我的应用程序的演示部分。在同一层内，我有一个单独的文件夹用于实现域中定义的服务。

我的计划是使用依赖注入进行依赖解析。最初，我想将与 DI 相关的代码放在 Infrastructure 中。但问题是在我映射服务时它会导致循环引用因为实际的服务实现在我的 Web 项目中，并且 Web 项目已经在引用基础设施。我不能将具体服务移动到另一层，因为它违反了洋葱架构的原则（传递依赖）。

任何线索表示赞赏。

2 部分问题...我的解决方案中有几个资源文件 (.resx)，主要用于字符串翻译。例如，Errors.resx、Validation.resx 和 Enums.resx。

第 1部分：如果我没有 Enums 资源文件，我假设我应该将所有资源文件放在 UI 层中，可能在它自己的程序集中（如“Company.App1.MVCApp.Resources”）并从Web 应用程序（Company.App1.MVCApp）...将资源文件放在 UI 层中是否正确？

第 2 部分：Enums.resx 文件包含与枚举成员相关的描述性字符串（使用 Description 属性），在我的 UI 中，有时在域服务中，我可能需要在其翻译中访问描述性字符串。我考虑过将它存储在核心/域层中的某个地方，比如 Company.App1.Core.Resources ...？或者我应该在核心层创建一个抽象，然后在基础设施层的某个地方实现 ResourcemManager 以坚持正确的洋葱架构..？

I am learning the well-known Onion Architecture from Jeffrey Palermo. Not specific to this pattern, but I cannot see clearly the separation between repositories and domain services. I (mis)understand that repository concerns data access and service are more about business layer (reference one or more repositories).

In many examples, a repository seems to have some kind of business logic behind like GetAllProductsByCategoryId or GetAllXXXBySomeCriteriaYYY.

For lists, it seems that service is just a wrapper on repository without any logic. For hierarchies (parent/children/children), it is almost the same problem : is it the role of repository to load the complete hierarchy ?