使用 Web 参考分隔装配体
我很好奇其他人会如何处理这种情况。我有一个包含地址对象的域层。然后我有一个使用这个对象的应用程序。此外,还有一个 asp.net asmx Web 服务,可通过第三方 Web 服务执行地址验证。
我很好奇如何处理这个功能。我不想将访问 Web 服务的服务引用和代码放在域层中。把它放在应用层似乎也是错误的。
我当前的最佳解决方案是创建引用原始域层和验证 Web 服务的第三个程序集。这使我的域层更加干净,没有外部引用。你会如何处理这种情况?
I am curious how others would handle this situation. I have a domain layer that includes an Address object. I then have an application that uses this object. Additionally, there is an asp.net asmx web service that performs address validation by going out to a third party web service.
I am curious how to deal with this functionality. I don't want to put the service reference and code to access the web service in the domain layer. It also seems wrong to put it in the application layer.
My current best solution is to create a third assembly that references the original domain layer AND the validation web service. This keeps my domain layer a bit cleaner with no external references. How would you handle this situation?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
那么,验证地址是应用程序 (UI) 逻辑的一部分还是域要求的一部分?
如果它是应用程序功能,则它位于应用程序层。如果它是核心领域功能,则它位于领域层。
如果您担心耦合 - 例如,如果您认为将来可能决定使用不同的地址验证服务 - 则对其进行抽象。创建一个接口和一个包装类:
或者无论逻辑是什么。然后让您的应用程序(或域模型)依赖于 IAddressValidator 而不是服务本身,并从最外层引入具体的 IAddressValidator 实例。
您可以将核心
IAddressValidator
接口放入域模型中,并将FooAddressValidator
保留在仅由可执行文件引用的外部程序集中。这样,您的域实际上并不依赖于 Web 服务,但您仍然将地址验证作为域逻辑的一部分。这也使得使用地址验证组件的任何内容都更容易测试,因为您实际上不需要进行 Web 服务调用,您可以为此使用不同的
MockAddressValidator
实例。Well, is validating the address part of the application (UI) logic or part of your domain requirements?
If it's an app function, it goes in the app layer. If it's a core domain function, it goes in the domain layer.
If you're concerned about coupling - for example, if you think that you might decide to use a different address validation service in the future - then place an abstraction over it. Create an interface and a wrapper class:
Or whatever the logic is. Then make your application (or domain model) depend on
IAddressValidator
instead of the service itself, and fan in a concreteIAddressValidator
instance from the outermost layer.You could put the core
IAddressValidator
interface in your domain model and keep theFooAddressValidator
in an external assembly that's only ever referenced by the executable. That way your domain isn't actually dependent on the web service, but you still have address validation as part of your domain logic.This also makes whatever uses the address validation component a lot easier to test, since you don't actually need to make web service calls, you can use a different
MockAddressValidator
instance for that.