解决方案架构分层 [英] Solution Architecture Layering

问题描述

我现在是一个正在构建新系统的团队的开发人员，我对所提议的架构有疑问。一些提出的想法似乎与那里的技术相反。所以这里。

I'm now a developer in a team working on a new system being built and I have questions regarding the proposed architecture. Some of the proposed ideas seem counter intuitive to the technologies that are out there. So here goes.

我对使用依赖注入的典型基于Web的系统的理解是这样的。 DataInterface，DataLogic，BusinessInterface，BusinessLogic，DomainModels（持久性模型），ViewModels以及用于参数的MVC Web项目。在MVC项目中配置UnityDI
，说明正在使用哪些接口及其实现。在这种情况下，所有DLL都是整个Web解决方案的一部分，并在单个Web服务器中运行。 

My understanding of a typical web based system using dependency injection goes like this. DataInterface, DataLogic, BusinessInterface, BusinessLogic, DomainModels (Persistence Model), ViewModels and for argument sake a MVC web project. Configure UnityDI in your MVC project to say what interfaces and their implementations are being used. In this instance all your DLLs are part of the entire web solution and run in a single web server. 

另一种选择是使用WCF并为您的业务和数据层配置DI。然后有一个MVC项目，它有一个对你的WCF的服务引用。我有意提到WCF（SOAP）而不是REST服务。在为WCF创建服务引用
时，这必然会破坏松散耦合代码的目的？无论如何，原则上我不介意这个想法，因为它将Web项目的处理负载与业务逻辑分开，假设WCF托管在其他地方。

Another alternative is to use WCF and configure DI for your business and data layers. Then have an MVC project that has a service reference to your WCF. I'm purposefully mentioning WCF (SOAP) as opposed to REST services. When creating a service reference to a WCF this must presumably defeat the purpose of having loosely coupled code? Anyway, in principle I don't mind this idea as it separates the processing load of the web project from the business logic, assuming the WCF is hosted somewhere else.

可能的建议是为您的数据层提供单独的WCF服务，为您的业务层提供单独的WCF。您的MVC项目将调用WCF业务逻辑，您的WCF业务逻辑将调用WCF Datalayer。我问为什么有人会这么做？b $ b对我而言，这并没有真正的好处，事实上增加了无根据的复杂性。除此之外，计划是使用Entity Framework（我喜欢），但sql数据结构将在几十个数据库中分离。例如
一个数据库中的客户表和另一个数据库中的预订等等原则上，将负载分散到多个数据库似乎是一个好主意，但是由于模型和参照完整性之间没有联系，因此ORM变得难以处理。虚构。

The possible proposed idea is to have separate WCF services for your datalayer and a separate WCF for your business layer. Your MVC project will call the WCF business logic and your WCF business logic will call the WCF Datalayer. I'm asking why the hell would anyone do this? To me there is no genuine benefit for this and in fact adds unwarranted complexity. In addition to this the plan is to use Entity Framework (which I like) but the sql data structure is to be separated over dozens of databases. For example Customer tables in one database and bookings in another etc etc In principle it seems like a nice idea to spread load over numerous databases but then ORM becomes awkward to work with as there are no linkages between models and referential integrity is imaginary.

如果我愚蠢我想知道，也许我对这项技术的理解是否已经解决？但我认为我有真正的顾虑并想要意见。

If I'm being daft I'd like to know, maybe my understanding of the technology is floored? But I think I have genuine concerns and would like opinions.

推荐答案

那里有很多讨论点，所以我会对其中几个提出意见。我不认为你关心的是WCF本身，所以我想你想知道为什么你可能会将这些层次的物理分离？ 做这个
的几个原因; 1）安全性，在某些情况下，数据库是系统的皇冠上的宝石。物理隔离允许更多的安全网关，进入Web服务器将更难访问下一层。 2）安全/重用 - 您的网络层是
一个到您服务的展示渠道，通过分离层，您可以更轻松地将这些层重新用于不同的渠道，例如：移动，企业对企业等等。现在已经说过所有这一切都很少见，你需要做所有这些，而且通常是b
只是有人在阅读有关如何构建系统而不是查看系统的教科书实际问题。是的，它可能是过度设计的解决方案。

There is quite a few discussion points there so I'll give my opinion on a couple of them. I don't think you're concerned with WCF per se, so I think you're wondering why you might have the physical separation of the tiers? A couple of reasons for doing this; 1) Security, in some situations the database is the systems crown jewels. Having a physical separation allows for more security gateways, break into the web server it will be harder to access the next tier. 2) Security/Reuse - Your web layer is one presentation channel to your services, by separating out the tiers you can more easily re-use those layers for different channels, e.g. mobile, business-to-business, etc. Now having said all that it's pretty rare you need to do all of that and often it's just someone reading a text-book on how to architect a system rather than looking at the actual problem. So yes, it could be and over-engineered solution.

我的第二点是SQL Server。你提到性能可能是一个优势。如果需要跨服务器连接，那可能是真的，也可能不是。但是，可能是该解决方案需要一种面向服务的体系结构，其中系统隔离
数据是一个明显的优势，您不能也不应该跨服务器加入。这也包括任何ORM请求。

My second point is SQL Server. You mention that performance could be an advantage. That could be true, or not if it will require cross server joins. However, it could be that the solution is calling for a Service Orientated Architecture where isolating the data by systems is a clear advantage, you cannot and should not join across the servers. That would also include any ORM requests.

第三点，你为什么使用实体经理（EM）？如果只是针对ORM，则会有更小的解决方案。 EM非常适合管理对象的身份，但我很少将其视为无状态解决方案（web）的优势。

Third point, is why are you using Entity Manager (EM)? If it's just for ORM then there are smaller-footprint solutions. EM is great for managing identity of objects but I've rarely seen that as an advantage for a stateless solution (web).

这篇关于解决方案架构分层的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！