如何使用弹簧的分层架构仍然遵循面向对象的结构？ [英] How to use Layered architecture of spring and still follow object oriented structure?

问题描述

我学习了spring及其分层结构（控制器，服务和dao）

I learned spring and its layered structure(controller,service and dao)

@Controller("userController")

@service("userService")
@Transactional(     propagation = Propagation.REQUIRED,     isolation = Isolation.DEFAULT,      readOnly = true)

@Repository("userDAO")

现在我很困惑如何利用优秀的OOPS实践 （比如这个）用这些分层结构来制作一个大项目（现实世界有更复杂的业务逻辑，然后通常提供示例应用程序）。我还想使用这些spring事务和框架提供的其他功能。
有些人可以帮我解决这个问题，或者参考开源项目来澄清我的疑问。

Now I am confused how do I make use of good OOPS practices (like this) with these layered structure to make a big project( real world have more complex business logic then sample applications usually provided). I also want to use these spring transaction and other features provided by framework. Can some please help me out with it or refer to open source project which clarifies my doubt.

推荐答案

简而言之

分层架构只会简化代码的可维护性和一致性，当它变得庞大而复杂时。

Layered architecture will just ease the code maintainability and consistence when it becomes huge and complex.

要记住的事实是在执行之前要做一个合适的软件设计。

The fact to remember is that to do a proper software design before doing the implementation.

• 封装 - 特定于域模型的业务逻辑应该在其中。


• 抽象 - 在抽象中编写公共业务逻辑时，根据服务分组隔离接口。


• 继承 - 在起草时使用您的域对象


• 多态性 - 当您想要更改子模型的业务逻辑时继承继承。

• Encapsulation - Business logic specific for a domain model should go inside it.
• Abstraction - Segregate the interfaces according to the grouping of services while writing the common business logic in the abstraction.
• Inheritance - Use when you are drafting your domain objects
• Polymorphism - Along with inheritance when you want to change the business logic of child models.

详细

下面我正努力提供一个用于此讨论的ERP应用程序示例。希望ERP是一个足够的大项目来查看业务逻辑的复杂性。

Below I'm trying my best to provide an example of an ERP application for this discussion. Hope an ERP is a sufficient big project to view the business logic complexity.

以下描述适用于任何需要理解的开发人员并在Spring（或任何其他框架）中使用分层项目结构。

The below description is for any developer who need an idea to understand and make use of layered project structure in Spring (or any other framework).

但请注意，这些不是要遵循的规则，而是要使用的最佳实践。 ：）

---

1。数据访问层 - 模型/域对象

这包含实际表到类的映射。

This contains the mapping of actual tables to classes.

在ERP示例中，您可以获得模型： CustomerOrder ， CustomerOrderLine

In an ERP example, this is where you get the models: CustomerOrder, CustomerOrderLine

这还包含子域对象的en-capsuled逻辑和self的域逻辑。例如， CustomerOrderLine 是 CustomerOrder 的子项。没有父母，孩子就不能存在。因此，父母将完全控制在其中构建孩子。即业务逻辑封装。。即：添加CustomerOrderLine ， RemoveCustomerOrderLine 等。当谈到自域逻辑时， ApproveCustomerOrder ， RejectCustomerOrder etc ..

This also contains the en-capsuled logic of child domain objects and the domain logic of self. For example, the CustomerOrderLine is a child of CustomerOrder. The child cannot exists without the parent. So the parent will have the full control of building the childs within it. ie Business logic encapsulation.. ie: Add CustomerOrderLine, RemoveCustomerOrderLine etc.. And when it comes to self domain logic, ApproveCustomerOrder, RejectCustomerOrder etc..

< hr />
2。数据访问层 - 存储库

这包含简单的CRUD到数据库，只有 SELECT，INSERT，UPDATE和DELETE SQL 。您可以在Spring中使用存储库模式以及 Spring Data JPA 。

This contains nothing but simple CRUD to database with SELECT, INSERT, UPDATE and DELETE SQLs. You can use repository pattern in Spring along with Spring Data JPA.

重点说明：不要写除非您的逻辑是高度数据密集的，否则此层中的任何复杂逻辑

在这种情况下，您可能必须编写一个或多个函数来执行复杂的查询语句。 （最好在 JPQL ）

In that case you might have to write one or more functions to do complex query statements. (Preferably in JPQL)

在ERP示例中，这是你的位置为写入逻辑， GetCustomerOrderByCustomer ， GetCustomerOrderLines ， GetOrderByStatus

简单来说，这一层定义了应用程序与外部实体（如数据库）的通信方式。

In simple terms this layer defines how the application will communicate with the outside entities such as Database.

---

3。服务层

这是您应该放置涉及多个未连接（非子 - 父）域模型的复杂业务逻辑的地方。这些将在Web控制器和Rest API控制器中重用。

This is the place where you should put your complex business logic which involved Multiple unconnected (not child - parent) domain models. These will be reused in Web Controllers and Rest API Controllers.

因此，为了保持一致性并实施安全性，我宁愿所有业务逻辑甚至包括在域模型中编写的业务逻辑都被包装在这一层。

So to maintain the consistence and to implement the security, I would prefer all the business logic even which were written in the domain models gets wrapped up at this layer.

在ERP例子中，这是你编写逻辑或包装在域模型中编写的逻辑的地方。例如 CreateCustomerOrder ， ListCustomerOrder ， ApproveCustomerOrderLine ， ReleaseCustomerOrder ，...

如果这些逻辑应该执行与其他模型逻辑一样，那些也应该在服务层内的序列中调用。例如。

其他关于复杂业务逻辑的示例

如果您想为供应商创建采购订单，那么客户订单是发布。

然后，这可以通过创建名为 SupplyChainService 的服务来完成。使用Spring AOP绑定到 CustomerOrderService.ReleaseCustomerOrder 。

Then, this can be done by creating a service called SupplyChainService binded using Spring AOP to the CustomerOrderService.ReleaseCustomerOrder.

的 4。控制器

控制器可以分为两类，即：Web控制器和REST控制器。在该层中不应该实现业务逻辑，因为在Web和API级别调用可能需要相同的逻辑。

Controllers can be categorized in two, namely: Web Controllers, and REST Controllers. No business logic should be implemented in this layer because the same logic can be required to call in Web as well as in API level.

In在ERP系统中，您可以在此处为客户订单表单编写控制器，以输入数据并保存以创建新的客户订单。

In the ERP system, this is the place where you will write the controller for your customer order form to enter data and save it to create a new customer order.

这也是您创建像REST这样的API控制器以通过移动应用程序或Windows客户端创建客户订单的地方。

This will be the place you will also create a API controller like REST to create the customer order via a mobile application or from a windows client.

感谢SO社区向我展示了我在这个答案中没有涉及OOP原则的领域

这篇关于如何使用弹簧的分层架构仍然遵循面向对象的结构？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！