- html - 出于某种原因,IE8 对我的 Sass 文件中继承的 html5 CSS 不友好?
- JMeter 在响应断言中使用 span 标签的问题
- html - 在 :hover and :active? 上具有不同效果的 CSS 动画
- html - 相对于居中的 html 内容固定的 CSS 重复背景?
我想像这样模拟服务
public class FooService
{
public GetById(ISecurityContext context, id)
{
//checking context has right to view
//calling Foo repository to getById
}
public Add(ISecurityContext context,Foo fooEntity)
{
//checking context has right to add
//calling Foo repository to add
}
}
在上面的方法中我想传递不同类型的 SecurityContext所以我所做的是
Public Interface ISecurityContext
{
}
UsernamePasswordContext : ISecurityContext
{
public string Username { get; set; }
public string Password { get;set; }
}
SessionContext : ISecurityContext
{
public string SessionId {get ; set;}
}
所以在我的账户服务中我有一个方法
public class AccountService
{
public Account GetAccountFromSecurityContext(ISecurityContext context)
{
if(context is UsernamePasswordContext)
return GetAccountByUsernamePassword(context.Username,context.Password);
else if (context is SessionContext)
return GetAccountBySessionId(context.SessionId);
// more else if for different type of context
}
}
在上面的代码中我不喜欢那么多 if else所以我尝试引入多态性
所以在我的 ISecurityContext 接口(interface)中我添加了一个所有子类都将实现的 GetAccount 方法
Public Interface ISecurityContext
{
Account GetAccount();
}
UsernamePasswordContext : ISecurityContext
{
public string Username { get; set; }
public string Password { get;set; }
public Account GetAccount()
{
//call account service
GetAccountByUsernamePassword(this.Username,this.Password);
}
}
我的账户服务会变成这样
public class AccountService
{
public Account GetAccountFromSecurityContext(ISecurityContext context)
{
context.GetAccount();
}
}
但这里的问题是我正在从我的 UsernamePasswordContext POCO 调用服务/存储库,这会破坏 DDD
那么我可以通过哪些其他方式对这种情况进行建模。
最佳答案
我认为您离解决方案不远了。在这种情况下,我会在您的 AccountService
中注入(inject)一个工厂,它将承担 if..then..else
的责任。然后,工厂可以使用许多可能的解决方案之一。
我马上要做的一个更改是让您的 AccountService 实现一个接口(interface),以便以后更容易注入(inject)。假设您正在使用某个 IOC 容器,您不必太担心依赖性,因为您让容器处理所有这些。
这是您已有的部分,并进行了一些小的调整:
public class Account
{
//some account information and behavior
}
public interface ISecurityContext
{
}
public class UsernamePasswordContext : ISecurityContext
{
public string Username { get; set; }
public string Password { get; set; }
}
public class SessionContext : ISecurityContext
{
public string SessionId { get; set; }
}
这是您的帐户服务及其实现:
public interface IAccountService
{
Account GetAccountFromSecurityContext(ISecurityContext securityContext);
}
public class AccountService : IAccountService
{
readonly IAccountFactory _accountFactory;
public AccountService(IAccountFactory accountFactory)
{
_accountFactory = accountFactory;
}
public Account GetAccountFromSecurityContext(ISecurityContext securityContext)
{
Account account = _accountFactory.Create(securityContext);
return account;
}
}
因此,您可以在这里看到我注入(inject)了一个 IAccountFactory
,它将处理 Account
对象的实际创建(检索,无论什么)。此时我们只关心帐户是否被创建/检索...我们不关心如何创建/检索。
有几种方法可以实现这样的工厂。一种方法是使用一种策略模式,其中您有一个知道如何解析帐户的小部件列表。然后你只需选择匹配的小部件(策略)并执行它。与此类似的是使用 IOC 或服务定位器解析先前已在应用程序配置中注册的类型的工厂。
以示例的方式,这是使用 CommonServiceLocator
的 IAccountFactory
的一种可能实现:
public interface IAccountFactory
{
Account Create(ISecurityContext securityContext);
}
public class ServiceLocatorAccountFactory : IAccountFactory
{
readonly IServiceLocator _serviceLocator;
public ServiceLocatorAccountFactory(IServiceLocator serviceLocator)
{
_serviceLocator = serviceLocator;
}
public Account Create(ISecurityContext securityContext)
{
var resolverType = typeof (IAccountResolver<>).MakeGenericType(securityContext.GetType());
dynamic resolver = _serviceLocator.GetInstance(resolverType);
return resolver.Resolve(securityContext);
}
}
我这里的工厂进入服务定位器上下文并获取与我们的安全上下文匹配的任何解析器。以下是可能的解析器的几个示例:
public interface IAccountResolver<in TSecurityContext> where TSecurityContext : ISecurityContext
{
Account Resolve(TSecurityContext securityContext);
}
public class UsernamePasswordAccountResolver : IAccountResolver<UsernamePasswordContext>
{
readonly IRepository _repository;
public UsernamePasswordAccountResolver(IRepository repository)
{
_repository = repository;
}
public Account Resolve(UsernamePasswordContext securityContext)
{
var account = _repository.GetByUsernameAndPassword(securityContext.Username,
securityContext.Password);
return account;
}
}
public class SessionAccountResolver : IAccountResolver<SessionContext>
{
public Account Resolve(SessionContext securityContext)
{
//get the account using the session information
return someAccount;
}
}
唯一剩下的就是在您的 IOC 容器中注册解析器,以便在服务定位器尝试在工厂中解析它们时可以找到它们。
关于c# - 如何在 DDD 和存储库模式中对此建模,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/9312462/
这里有一个很大的设计缺陷,但我无法解决它: 业务需要有点涉及,所以我会尽量保持简单。 我们有一张购物表和一张退货表。当进行退货时,我们必须找到与数据库中最早购买的退货匹配,并将其记录在“已应用退货”表
在我的家庭项目中,我遇到了确定域对象类型的问题。 领域:公交时刻表 限界上下文:路由(公共(public)交通基础设施,ctx1)、时间表(调度,ctx2) 对象: Station - 描述一个公交车
我有一个名为“产品类型”的值类型,它被分配给了一个产品。 (一个产品有一个产品类型) 为了允许用户从列表中选择类型,我将填充一个下拉列表。在哪里检索产品类型列表最合适?一个实现存储库模式的类? 编辑:
域这个词在 DDD 中究竟是什么意思?我一直在阅读定义……虽然我看到了域模型之类的东西并理解模型是什么 - 域模型是什么意思? 域实际上是什么意思? 谢谢 最佳答案 域是指您的应用程序解决的主题。 例
DDD 中的域模型应该与持久性无关。 CQRS 要求我为我不想在读取模型中包含的所有内容触发事件。 (顺便说一下,将我的模型拆分为一个写模型和至少一个读模型)。 ES 要求我为所有改变状态的事件触发事
Eric 在他的书中触及了 的主题。模块 很少。他也没有通过示例讨论模块结构与有界上下文的关系。限界上下文是否包含模块或模块包含限界上下文?当应用程序具有 DDD 时,它的可扩展性有多容易? 在我们设
前言 笔者于2021年入职了杭州一家做水务系统的公司,按照部门经理要求,新人需要做一次个人分享(主题随意)。 当时笔者对DDD充满了浓厚的兴趣,之前也牛刀小试过,于是就决定班门弄斧Show一下
上部分 模型驱动设计的构造块 为维护模型和实现之间的关系打下了基础。在开发过程中使用一系列成熟的基本构造块并运用一致的语言,能够使开发工作更加清晰而有条理。 我们面临的真正挑战是找到
3. 领域对象的生命周期 。 每个对象都有生命周期,如下图所示。对象自创建后,可能会经历各种不同的状态,直至最终消亡——要么存档,要么删除。当然很多对象是简单的临时对象,仅通过调用构造函数来创建
为了保证软件实践得简洁并且与模型保持一致,不管实际情况如何复杂,必须运用建模和设计的实践. 某些设计决策能够使模型和程序紧密结合在一起,互相促进对方的效用。这种结合要求我们注意每个元素的细节
大家好,我是 ddd 设计的新手,正在尝试使用这种在 C# 中工作的模式开发我的第一个应用程序 在我的应用程序中,我有一个包含子实体 Assets 的聚合合约,当添加或结算 Assets 时,我应该在
我正在尝试弄清楚如何使项目的一些消费者(业务客户)的不变量保持一致,他们对同一版本的聚合根有自己的要求。让我们以客户为例,提出假设性问题以满足以下愚蠢的逻辑: public class Custome
我见过一些具有实体值对象表示的 DDD 项目。它们通常显示为 EmployeeDetail、EmployeeDescriptor、EmployeeRecord 等。有时它包含实体 ID,有时不包含。
我试图了解如何表示某些 DDD(域驱动设计)规则。 遵循蓝皮书约定,我们有: 根实体具有全局身份并负责检查不变量。 根实体控制访问,并且不会被其内部结构的更改所蒙蔽。 对内部成员的 transient
我对 ddd 中的验证方法有疑问。我已经阅读了相当有争议的意见。有人说这应该在实体之外,其他人说这应该放在实体中。我试图找到一种我可以遵循的方法。 例如,假设我有带有电子邮件和密码的 User 实体。
寻找有关如何解决此问题的建议,并了解域驱动设计是否真的是这里的最佳模式。 我的客户正在重新构建其几近过时的工具和服务堆栈。客户是一个快速扩张的电子商户。它的核心产品是它的大型电子商务网站。围绕该网站,
我很难找出实现依赖于数据库中存储的数据的业务规则验证的最佳方法。在下面的简化示例中,我想确保用户名属性是唯一的。 public class User() { public int Id { g
情况: 要处理域事件,Jimmy Bogart proposed 一种将事件存储在聚合中的方法。 在我看来,这是一种非常方便的方法。但是,域服务中的域事件怎么办? 域服务不应该有状态(stateles
我正在处理遗留项目,试图改进项目结构。我的问题是我应该如何组织代码结构。我看到两个选项: #1 business-domain / layer app/ ----accout/ --------app
根据 DDD 原则,所有处理与特定聚合根对象相关的实体的 CRUD 操作都应该由聚合根进行。 但是我们如何从 aggr 根中仅更改实体的单个属性?我们应该在实体中有 setter 方法吗?这些方法应该
我是一名优秀的程序员,十分优秀!