UI、业务逻辑层、数据层以及放置 Web 服务的位置
我们正在开发一个网络应用程序。我们希望可能重用我们在这里为不同的应用程序所做的工作，该应用程序将使用相同的数据库，并使用相同的业务规则来读取和写入所述数据库。
哪种设计更正确
让 UI 调用 Web 服务，这将使用包含业务逻辑的业务对象，该业务对象将与数据访问层对话。
让 UI 使用包含业务逻辑的业务对象，这将调用 Web 服务，然后与数据访问层通信。
让 UI 使用包含业务拥有包含业务逻辑的 UI 用户业务对象，它将与数据访问层对话。
We are developing a web application. We want to possibly reuse the work we do here for a different application that will use the same database, and use the same business rules for reading and writing to said database.
Which design would be more correct
Having the UI call web services, which would use business objects containing the business logic, which would talk to the data access layer.
Have the UI use business objects containing the business logic, which would call web services, which would then talk to the data access layer.
Have the UI user business objects containing the business logic, which would talk to the data access layer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
不要将逻辑设计与物理设计混合在一起。逻辑设计在层上运行，而物理设计则在层上运行。 Web Service 不是一个层。这只是一个层次。
逻辑设计有标准做法：UI层->UI层。 BL层->达尔
在物理设计中，所有层都可以驻留在连接本地数据库的一个客户端应用程序中，也可以分布在远程层上。但对于分布式应用程序，通常会再添加一层：应用程序层，它隐藏了 BL 层通过线路进行的通信。
Don't mix logical design with physical design. Logical design operates over layers and physical design - tiers. Web Service is not a layer. It is simply a tier.
In logical design there is standard approach: UI layer-> BL layer -> DAL
In physical design all layers can reside within one client-side application connecting local database, or can be distributed over the remote tiers. But for distributed applications usually is added one more layer: Application layer, which hides from BL layer communication over the wire.
我想说的是第三个。我倾向于将 Web 服务视为另一个表示层。
可以这样想：您有一个 Web UI，它调用您的业务层代码来执行诸如创建新用户 (User.Add)、查找与给定描述匹配的所有产品 (Products.FindByDescription) 等操作。
您可以现在，重新使用相同的业务层代码来构建一组面向公众的 Web 服务，供第三方使用。可以有一个方法来添加用户 - 调用您的内部 User.Add() 方法，另一个方法来查找产品等。
您得到的是一组相同的底层数据和业务逻辑的并行演示/界面。
在幕后（完全超出 Web 服务或 UI 层的范围），业务层调用负责物理查询数据库的数据访问层。如果您要更改为不同的 DBMS，理想情况下（理论上）您应该能够为新数据库重建数据层，并使一切正常工作。
您的业务层包含一些规则，例如用户名必须为 4 到 15 个字符长；用户只能搜索和加载他们有权访问的商店中的产品； 如果您决定更改业务规则（例如
允许用户在其所在州的任何商店中搜索产品），那么您可以一次性更改它，而无需触摸 Web 服务或 UI 来实现它工作。
I would say the 3rd one. I tend to think of web services as another presentation layer.
Think of it this way: you have a web UI, which calls your business layer code to do things like create a new user (User.Add), find all products that match a given description (Products.FindByDescription), etc.
You can now re-use that same business layer code to build a set of public-facing web services for 3rd parties to make use of. There can be a method which adds a user - that calls your internal User.Add() method, another one to find products, etc..
What you get is a parallel set of presentations/interfaces to the same underlying data and business logic.
Behind the scenes (totally out of the scope of web services or UI layers), the business layer calls a data access layer that takes care of physically querying the database. If you were to change to a different DBMS, you should ideally (and in theory) be able to rebuild the data layer for the new database and have everything simply work.
Your business layer contains the rules like a username has to be 4 to 15 characters long; users are only allowed to search for and load products that are at a store they have access to; etc.
If you decide to change a business rule - like a user is allowed to search for products in any store in their state - then you change it in once place, and don't have to touch the web service or UI to make it work.
根据您的描述，您没有提供需要使用 Web 服务层的原因。假设您的 UI 系统可以访问您的数据库，即在防火墙后面的同一网络内，您的网站 UI 代码（我假设是服务器端）将使用的基本业务对象层可以满足您的要求。
当 UI 系统和数据层之间的距离开始跨越数据访问层或业务逻辑层将开始遇到困难的边界时，引入 Web 服务层。
From your description, you haven't provided a reason why you would need the use of a web service layer. Assuming your database is reachable by your UI system, i.e. within the same network behind your firewall, a basic business-object layer that your website UI code (server-side, I'm assuming) will employ meets your requirements.
Bring in a web service tier when the distance between your UI system and your data layer starts to cross boundaries that a Data access layer or Business logic layer would begin to encounter difficulties.
就设计是否“正确”而言，在没有完整背景的情况下，实际上不可能对设计的正确性给出 100% 的答案。有哪些要求（功能性和非功能性）？您想实现什么设计目标？每个目标有多重要？
您的问题提到的唯一目标是您希望在另一个应用程序中重用业务逻辑。当我想以标准方式重用应用程序的业务逻辑时，我选择 Web 服务。因此，仅根据您的一个要求，我会说选项 1（UI->Web 服务->业务层->数据层）是一个不错的选择。
In terms of the design being "correct" or not, it's not really possible to give a 100% answer to the correctness of a design without the full context. What are the requirements (functional and non-functional)? What design goals do you want to fulfill? How important is each goal?
The only goal your question mentions is that you want to reuse the business logic with another application. When I want to reuse the business logic of an application in a standard way I choose web services. So based solely on your one requirement I would say that option 1 ( UI->Web Service->Business Layer->Data Layer ) is a good choice.
从逻辑上讲，Web 服务属于 UI 层。想想“用户”不仅是一个人，而且是另一个系统，它就变得清晰了。在这些逻辑层之间保持严格的关注点分离将使您能够轻松地实现和维护您的应用程序。
Logically, web-services belong in the UI layer. Think of "User" being not only a human but another system and it becomes clear. Maintaining strict separation of concerns between these logical layers will allow you to easily implement and maintain your application.
查看：http://www.icemanind.com/layergen.aspx
应该如此go 的做法是，UI 层位于顶部，数据层位于底部，业务层位于两者之间。每层只能与其下面的层通信。所以 UI 仅与业务层对话...业务层仅与数据层对话。你的 UI 永远不应该与数据层对话，并且你的数据层永远不应该与你的 UI 交互。
除非你有理由使用网络服务，否则我不会。
Check Out: http://www.icemanind.com/layergen.aspx
The way it should go is, you have your UI layer on top, your data layer on the bottom and your business layer in between the two. Each layer can only communicate with the layer below it. So the UI talks to the business layer only...the business layer talks to the data layer only. Your UI should never talk with the data layer and your data layer should never interact with your UI.
Unless you have a reason to use a web service, then I wouldn't.
您听说过有关服务层的事情吗？我认为您可以为事务和操作使用服务层，并且使用外观层可以帮助您在访问业务层后直接或间接隔离和管理从 UI 到数据访问层的访问。这取决于你的要求。
Do you hear anything about Service layer ? I think you can use a service layer for your transactions and operations and using a facade layer helps you to isolate and manage accessing from UI to data access layer directly or indirectly after visiting the Business layer . it depends on your requirements.