编程模式/架构问题 [英] Programming pattern / architectural question

问题描述

我目前正在处理一个项目，其中我有一个用于其他实体的 BankAccount 实体.

I am currently working on a project where I have a BankAccount entity for some other entity.

作为对银行实体、帐号和可选的 IBAN 的引用的每个银行帐户.

Each bank account as a reference to a bank entity, an account number and optionally an IBAN.

既然可以验证 IBAN，我如何确保为帐户设置的 IBAN 有效.什么是干净的架构方法?我目前有一个域层，没有任何其他层的参考，我喜欢这种干净的方法(我的灵感来自 Eric Evans DDD).幸运的是，无需访问任何外部系统即可执行 IBAN 验证，因此在这种情况下，我可以使用类似

Now since an IBAN can be validated, how can I ensure that when the IBAN is set for an account is valid. What would be a clean architectural approach? I currently have a domain layer without any reference to any other layer and I like this clean approach (I was inspired by Eric Evans DDD). Fortunately the IBAN validation can be performed without accessing any outside system so in this case I could have something like

puclic class BankAccount
{
  public string Iban
  {
     set { // validation logic here }
  }
}

但现在我在想，如果 IBAN 验证需要 SQL 服务器检查或外部 dll，我会使用什么方法.我将如何实施.我是否会创建一个传递给服务的 IBAN 值对象，该对象决定 IBAN 是否有效，然后将其设置为 BankAccount 实体?或者我会创建一个允许实例化 IBAN 并在之前执行验证的工厂吗?

But now I was thinking what approach I would use if the IBAN validation requires an SQL server check for example, or an external dll. How would I implement that. Would I create an IBAN value object which is passed to a service, that decides whether the IBAN is valid or not and after that set it to the BankAccount entity? Or would I create a factory which is allowed to instanstiate IBANs and performs validation before?

感谢您的帮助！

推荐答案

我会使用某种形式的控制反转.

I would use some form of Inversion Of Control.

具体来说，我将有一个名为 IIBANValidator 的接口.验证 IBAN 的各种方法应该实现该接口.例如:

To be specific, I would have an interface called IIBANValidator. The various means of validating the IBAN should implement that interface. For example:

interface IBANValidator {
    Boolean Validate(string iban);
}

class SqlBanValidator : IBANValidator {

    public bool Validate(string iban) {
        // make the sql call to validate..
        throw new NotImplementedException();
    }

}

然后，我将在 BankAccount 类中有一个方法，该方法接受一个实现 IIBANValidator 和 IBAN 编号的对象，其结构类似于(未进行任何优化):

Then, I would have a method in my BankAccount class which accepted an object that implements IIBANValidator and the IBAN number and was structured like (not optimized by any stretch):

Boolean SetIBAN(IIBANValidator validator, String iban) {
  Boolean result = false;
  if (validator.Validate(iban)) {
    Iban = iban;
    result = true;
  }

  return result;
}

此时您的 BankAccount 类不必依赖于您的验证器，您可以随意更换它们，最终它非常干净.

At this point your BankAccount class would not have to have a dependency on your validators, you could swap them out at will, and ultimately it's very clean.

最终代码如下所示:

BankAccount account = new BankAccount();
account.SetIBAN(new SqlBanValidator(), "my iban code");

显然在运行时你可以传递任何你想要的验证器实例.

Obviously at runtime you could pass any validator instance you wanted.

这篇关于编程模式/架构问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！