Tyl*_*hie 4 java architecture service persistence repository
我需要在Java EE环境中对三个软件体系结构层(下面列出)进行可靠的解释,这是我从多个上下文中获取的.简而言之,这就是我所获得的:
在浏览了多篇文章之后,我对服务层和持久层之间的区别位置感到困惑- 它们是否重叠或是彼此的同义词？我从来没有在真正相同的背景下听到过它们.
所有这些层是否总是使用/容易区分？
谢谢.
man*_*ish 14
的服务层封装应用程序的业务逻辑和计算.单词Service用于强调使用面向服务的设计原则建模的业务逻辑层可以由不同的消费者使用的点,例如,Web表示层,API集成层,远程移动客户端等.服务的例子可能是PayrollService,DiscountService,OrderService等这允许写一次,并在不同的技术,地点和应用的多个地方所消耗的业务逻辑.
在持久层负责提供数据访问操作服务层.为了遵循松散耦合的原则,服务层不必担心数据的存储方式和位置.它应该简单地将所需的业务逻辑应用于数据,这就是数据访问代码应该与业务逻辑代码(在任何严肃的企业应用程序中)分开的原因.
存储库是一种常用于实现持久层的设计模式.在许多其他方面,它允许将应用程序数据建模和管理为域模型(技术团队成员和业务用户共享对业务域的共同理解的方式).这允许使用域驱动设计.存储库模式也很有用,因为它允许服务层作为一致的接口访问所有(或至少大多数)数据源(大多数提供基于存储库的持久层的框架在所有存储库上提供基本的CRUD方法).仓库的例子可能是OrderRepository,PersonRepository,DepartmentRepository等Martin Fowler的网站上有一个存储库模式的很好的概述.
持久层也可以通过其他方式实现,最简单的方法是使用本机数据访问技术,如JDBC,ODBC,ADO.NET等.
现在,为了回答您的问题,服务和持久层应在正确构建的软件系统中分开,以提供系统的业务逻辑和数据访问组件之间的松散耦合(如果您同意业务逻辑和数据访问是两个独立的问题).有关将各个应用问题封装为单独组件的入门知识,请参阅SOLID原则.这两层之间的任何重叠都会很糟糕,因为它会导致硬耦合,可能的代码重复,分散的错误,代码缺乏灵活性等. 存储库是一种设计模式,是实现持久层的可能方式之一,尽管还有其他实现持久层的方法.以下视觉描述可能有所帮助:
------------------------------- -------------------------------
| W e b l a y e r | | A P I l a y e r |
------------------------------- -------------------------------
-------------------------------------------------------------------------------
| S e r v i c e l a y e r |
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
| P e r s i s t e n c e l a y e r |
-------------------------------------------------------------------------------
---------------------------
/ /
---------------------------
/ /
---------------------------
/ D a t a S t o r e s /
---------------------------
| 归档时间： |
|
| 查看次数： |
2847 次 |
| 最近记录： |