【限时免费】岁尾最强一次云计算大年夜会，看传统、社区、互联网企业若何碰撞？

在Spring框架中最常见的几个注解

@Controller, @Service, @Component, @Repository

个中@Component是一种通用名称，泛指随便率性可以经由过程Spring来治理的组件，@Controller, @Service, @Repository则是一种特定的组件，平日用来表示某种特定场合下的组件，比如@Repository用来表示仓库（数据层，DAO），并且Spring 框架会根据这种应用处景做些定制，比如@Repository同时具备了主动化的异常转换。类似的， @Service则用来表示办事层相干的类， @Controller则用来表示展示层（presentation）的类。

那Service是什么呢？

Service 表示了在软件分层设计中的Service层，用来贯穿连接数据层（DAO）和展示层（Presentation）。

为什么要在DAO层上加一层Service呢？

在某些简单的应用中，DAO层的功能和Service的功能很接近，甚至初学者会认为Service层做的工作和DAO层都一样，那为啥还要将Service层零丁拿出来做一遍呢？并且，很多场景下，Service层和DAO层同时存在，往往会增长代码复杂度，编码工作量，写的不好甚至会造成混淆。

举一个例子：

平日来说，DAO层应尽力坚削发单，其功能仅仅是供给了数据库的连接，以及最简单的增删改革诣Crud），有时还须要做些抽象，以词攀来连接应用不合技巧的数据库。除此之外，任何营业相干的操作都应当放到Service层，即Service层用来编写营业逻辑，即操作大年夜DAO层攫取的数据，或者将处理好的数据给DAO层，当应用Domain Driven Design时， 这两个类平日会放到同一个Domain（包）中，即便在简单的应用中，他们的代码可能极其类似，然则仍应当分别对待。而不是跳过service层（service）直接去应用DAO层（repository）来放营业逻辑数据。

2、在service层中，每个entity都有对应的service类时，service层会有过多的依附，甚至是轮回依附关系，而不是由松散耦合的service类构成service层，幻想中的service层应当是由具有单一义务的service类构成，并且这些service类具有松耦合关系，如不雅不是如许的service层，将难以懂得，保护和重用。

其次，在web应用开辟中，应用Service层可以将web类的晃荡限制在controller中，如许可以自力的测试service层

别的，还有一种情况，就是当应用极其复杂，须要同时应用多种数据库时，将大年夜DAO中获取数据的动作放到一路可以削减数据库的操作，并且可以包管数据的一致性。同时Service可以嵌套，是以如不雅须要应用不合的数据库时，可以在service中指定。

在Service中也可以放一些通知类的操作，比如发送邮件等，如许也可以保持controller的┞符洁。

还有一个潜在的好处是安然性，当应用service层担保DAO层后，数据库的链接是被service财揭捉?护起来的，如许如不雅客户端被某种情况攻下，其只能应用service层供给的有限数据，而无法直接进击数据库

别的，在Spring 框架中，security也是在Service层实现的。根据膳绫擎的逻辑，我们在实际开辟中，应当不去实现本身的DAO层，而是应用Spring Data JPA，因为Spring Data JPA已经实现了DAO层。

这种写法常见的问题有啥？

最常见的写法（或者是缺点的写法）有以下几种

1、面向范畴的模型对象仅仅用来存储应用中的数据，换句话说，是不太相符domain model 设计的

所有这些分层方法都是为懂得决应用大年夜小项目成长为大年夜项目时可能碰到的隐患，价值是在项目还小时，增长了项目标复杂度，往往一句代码就能搞定的工作，却要拆到三个类中去。然则太多的实际例子注解，如不雅没有好的架构，当小项目膨胀到必定水日常平凡，往往是无法保护的，只能全部推倒重写。

2、处理模型数据的营业逻辑分散在service层

3、每个entity都有对应的service类

如许写的原因很大年夜程度来源竽暌冠膳绫擎的分层理论，我们确切将应用分成了展示层（web layer），办事层（service layer），数据层（repository/dao），然则实际后不雅倒是一个极其宏大年夜的service层，这种写法可以算是一个面向过程开辟的代码（procedural code）， 而不是面向对象开辟。好处是简单，当营业不复杂时，确切没有须要应用一个宏大年夜的面向对象开辟框架（domain driven design）。

一个义务并不明白的service层重要有以下问题

1、营业逻辑分散在service层中，当我们须要确认或者检查某个营业逻辑时，可能要在多个service类中寻找，也许并不那么轻易，别的如不雅同样的营业逻辑在多个service类顶用到时，那么可能会存在大年夜量的反复代码，这种反复代码对于保护人员来说就是恶魔。

重要的解决办法是

1、将与entity相干的营业逻辑同一放到范畴模型对象相干的类中，即所谓的domain service中。如许做的好处时，传统概念中的service层仅仅处理应用相干的营业逻辑，即作为Application Service。 然后domain service中处理domain 内的营业逻辑。营业逻辑将按照domain和application的方法分开，轻易定位和保护。传统意义上的applicationservice层将变得整洁。

2、在domain service中我们将按照entity来编写对应的service，这些都是特定的service，很小，仅局面对很专一的功能。举例来说，如不雅应用中的某个service供给person类的crud， 同时还供给用户帐号的操作，那么我们应当将person的crud零丁放到一个service中，然后将用户帐号相干的操作放到另一个service中。

　　推荐阅读

　　MySQL等传统关系型数据库弱爆了！GPU数据库才是未来趋势！

【限时免费】岁尾最强一次云计算大年夜会，看传统、社区、互联网企业若何碰撞？ 数据库市场似乎已经良久没有足以撼动MySQL地位的数据库出现了，我们习惯于看到MySQL占据各大年夜数据库排行>>>详细阅读

本文标题：Spring 中的注解与分层思想

地址：http://www.17bianji.com/lsqh/40080.html

 1/2    1