简单的应用架构建议 [英] Simple application architecture advice

问题描述

我正在尝试创建一个小型演示 Web 应用程序，该应用程序松散耦合、高度可测试、具有漂亮干净的代码等.简而言之，我正在尝试以正确的方式做事.;)

I'm attempting to create a small demo web application that is loosely coupled, highly testable, has nice clean code, etc. In short, I'm experimenting with doing things the right way. ;)

我的 Wolfie 解决方案中目前有三个项目:

I currently have three projects in my Wolfie solution:

• Wolfie.Core - 包含业务实体
• Wolfie.Data - 包含数据访问代码，引用 Core.
• Wolfie.Web - 将成为一个 nancy 网站.

就目前而言，Core 对任何其他项目一无所知.Data 必须引用 Core，因为 Core 具有 Data 将返回的类型.所以此时我发现自己意识到 Web 需要同时引用 Core 和 Data 才能工作，因为实体类型在 Core 中，而数据库调用在 Data 中.

As it stands the Core knows nothing about any of the other projects. Data has to reference Core as Core has the types that Data will return. So at this point I find myself realising that Web will need to reference both Core and Data to be able to work as the entity type is in Core and the database calls are in Data.

Data 中的所有存储库类都有接口，因此可以模拟存储库进行测试.

All of the repository classes in Data have interfaces so that the repositories can be mocked out for testing.

我不认为我想将任何特定于数据库的代码或引用放入 Core，并且我希望将实体业务规则排除在数据之外.

I don't think I want to put any database specific code or references into Core, and I want to keep my entity business rules out of Data.

从 Web 引用这两个项目是否正确?或者是否需要 Web 和其他项目之间的另一个项目，以便 Web 只引用一个地方，而不负责调用数据方法等.

Is it correct to reference both projects from Web? or would another project between Web and the others be required so that Web only references the one place and isn't then responsible for calling Data methods etc.

我的目标是一种架构，其中我的核心应用程序独立于数据层和 Web 层.

What I'm aiming for is an architecture where my core application is independent of both the Data and Web layers.

我希望我已经一些有意义，我期待一些有用的回复.

I hope I've made some sense and I look forward to some helpful replies.

推荐答案

我认为您正在为一个合理的目标而努力，这将创建一个可靠的应用程序架构.我亲自开发了一个企业 Web 应用程序，该应用程序使用与您所描述的架构类似的架构，并且该应用程序非常适合该应用程序.

I think you are striving for a reasonable goal which will create a solid application architecture. I have personally worked on an enterprise web application that used a similar architecture to the one you are describing, and it worked very well for that application.

在该应用程序中，域业务逻辑被隔离在其自己的域"程序集(您的核心"程序集)中，并且没有引用 .NET 框架之外的任何内容.为了连接到外部业务组件，例如数据库和其他 Web 服务，有一个基础设施"程序集(您的数据"程序集).该应用程序的关键是基础结构程序集中的每个实现都在域程序集中进行了接口，并返回了域程序集对象(正如您所描述的).当然，这需要从基础设施到域的引用.

In that application, the domain business logic was isolated in its own "Domain" assembly (your "Core" assembly) and referenced nothing outside of the .NET framework. In order to connect to external business components, such as the database and other web services, there was an "Infrastructure" assembly (your "Data" assembly). The key for that application is that each implementation in the Infrastructure assembly was interfaced in the Domain assembly, and returned Domain assembly objects (just as you describe). This, of course, necessitated a reference from Infrastructure to Domain.

为了将它们联系在一起，一个WebApp"程序集(您的Web"程序集)引用了域和基础结构程序集，并使用 IoC 容器来解析所有应用程序依赖项.当请求进入 WebApp 时，它会解析适当的域"合同来为请求提供服务，从而启动 IoC 解析调用链.除了注册基础设施实现之外，WebApp 程序集并不关心基础设施程序集是否存在.

To tie it all together, a "WebApp" assembly (your "Web" assembly) referenced both the Domain and Infrastructure assemblies and used an IoC container to resolve all of the application dependencies. When requests came in to the WebApp, it would resolve the appropriate "Domain" contract to serve the request which would start the IoC resolution call chain. Outside of registering the Infrastructure implementations, the WebApp assembly does not care that the Infrastructure assembly exists.

该应用程序如此有效的原因是它实现了您在问题中所述的目标:

The reason this worked so well for that application is that it achieved the goals you stated in your question:

• 业务领域中没有外部引用.
• 业务领域应用程序完全独立于 Web 前端和数据库后端.

这为您的业务领域提供了很多的可测试性，并为前端如何与您的领域交互提供了很多的灵活性.事实上，正是这种灵活性使它如此易于测试.这种灵活性还有其他好处.例如，通过隔离您的业务域，如果您想部署和运行您的客户端，您可以轻松地编写一个新的 CLI 或 WPF 前端，该前端连接到文件系统后端，而无需更改业务域代码的碎片在本地机器上.

This lends a lot of testability to your business domain, and a lot of flexibility to how front-ends interface with your domain. In fact, that flexibility is what makes it so testable. That flexibility has other benefits as well. For instance, with your business domain that isolated, you could easily code up a new CLI or WPF front-end that hooked into a file-system back-end without changing a scrap of business domain code if you wanted to deploy and run your client locally on a machine.

尽管该示例可能看起来有些牵强，但在我上面引用的应用程序的情况下，开发团队正在考虑构建 Web 服务前端以补充现有的 MVC 网站前端.对于该团队来说，这只是一个现实的可能性，因为他们像您描述的那样设置了该应用程序.

Though that example may seem slightly far-fetched, in the case of the application I was referencing above, the development team is contemplating building a Web Services front-end to complement the already existing MVC website front-end. This is only a realistic possibility for that team because they setup that application like you are describing.

这篇关于简单的应用架构建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！