1.三层架构(不是本文重点,简单介绍一下)
1)用户界面层(UI层),主要职责是提供可用的功能给用户。用户界面层(一般是XXXView),主要职责是响应(识别)用户的请求操作(包括UI层返回及用户的输入数据) ,由请求操作调用相应的XXXController(或XXXManager)完成相应的业务逻辑;在这一层也还要对一些错误信息进行判断和处理(错误信息是和数据库没有关系的。
2)业务逻辑模块层(一般由XXXController或 XXXManager类模块组成),主要职责执行业务逻辑的计算,业务逻辑可以很简单,简单到只是简单的调用XXXDAO的一个save操作。也可以很复杂,复杂到要用到多个CXXXDAO(或者说是多个table表)才能完成。即使用到了多个table表,业务逻辑层也不应该直接用sql操作 table表,那样会带来维护的复杂度,这时应该新建一个能操作相关table的XXXDAO新类,让这个新类来完成业务逻辑要求的复杂的sql(或是复杂的存储过程)。
3)DAO层(即数据访问层)。主要职责完成各种各样的存储、查询操作。主要作用是向上提供不同的存储接口及查询。如saveUserAndXxx();getUserAdnXxx()等等;提供数据的简化访问的同时也屏蔽了数据库的存在,业务逻辑层不需要知道DAO层到底在用那个数据库,或者根本就没用。
理论知识说破天也就那样,关键还是实践,能把三层通过几个项目实践出来,从项目中不断认识三层架构,仔细分析架构的好处才是硬道理。
2.事务(不是重点,简单介绍一下)
事务(Transaction)是访问并可能更新数据库中各种数据项的一个程序执行单元(unit)。事务有四个属性(原子性、一致性、隔离性、持久性)。
原子性主要描述的是一个事务的不可分割性,要么都做要么都不做。
一致性主要描述的是数据库从一个一致性的状态变到了另外一个一致性的状态
隔离性主要描述的是事务执行的不被干扰性
持久性主要描述的是事务一旦提交那么数据库的改变是永久性的不会被其他操作影响。
3、事务在三层架构中的运用(这是重点)
网上也有许多人在议论,事务应该在三层架构中哪一层设计比较好。其实我个人认为没有好与不好之分,只有哪个在特定环境下比较合适。
我现在做着的这个项目中出现了这个问题,正好在这里唠叨唠叨。
首先说,数据事务肯定是在数据层,因为如果在数据层不写事务的话,那么涉及数据的回滚,就会出现问题。然而事务在逻辑层使用也是不可避免的,事务管理就是业务的范畴,所以事务处理应该在逻辑层中实现。(这是自己的理解,欢迎大家斧正)
通过这样的分析,就很容易知道我们要在逻辑层中事务开启、提交、异常回滚和关闭。而事务的实现其实是在数据层实现的。
我相信肯定会有人认为事务只写在数据层就行,在业务逻辑层用sqlConnection感觉很不正常,其实这个观点网上也有很多人认同,也有很多人是这样做的。那我我还是说没有正确与否,只有合适不合适,这要根据项目来确定。首先说在数据层写事务是没有问题,一样能够实现。那么两者有什么区别,这是我们要明白的,也是我们选择在哪里写事务的一个主要因素。
就像我刚才说的,我选择在业务逻辑层这样我只要在逻辑层的事务操作中只做一次连接即可,而在数据层那么我们可能就不仅仅是一次了吧!如果我们在一个多发性的操作中,可能我们就会应为这样一个连接没有处理好就会导致程序崩溃。
还是那句话,没有唯一的正确标准,只有在某种情况下适合的方案。
----------------------------------分割线--------------------------
如果我们在逻辑层使用事务的话,那么我们势必会在业务逻辑层中开启数据库连接,而我们的数据库连接一般都会写在一个数据库助手类(sqlHelper)中,这样我们就有可能面临业务逻辑层中创建数据库助手类对象了。这样做耦合度会变得很高。那么我们可以通过事务独立成立来降低这个耦合度。具体的事务类中主要实现数据库连接,开启事务处理和关闭连接等操作。
具体事务类代码实现:
我们在sqlHelper的代码就要这样实现事务处理即可:
那么我们在数据层只需实例化sqlHelper类并传递从逻辑层传过来的事务类还有数据库连接参数即可:
在逻辑层中进行事务开启和关闭等操作:
通过这样的设计,就可以在逻辑层实现事务管理,才数据层进行事务实现。
最后还是那句话,没有最好的,只有最合适的。这篇博文的观点仅仅是笔者的一些片面观念,如果有什么不对的地方,希望斧正。
分享到:
相关推荐
然而,由于服务之间的网络延迟、服务失败等问题,传统的单体应用中的事务管理机制(如ACID事务)在微服务环境下变得难以适用。因此,我们需要探讨在微服务架构下解决分布式事务的策略和标准化方法。 首先,我们来看...
- 定义:在微服务架构中,当一个事务跨越多个服务时,就需要采用全局事务的管理方式。 - 主要组成部分: - **AP(Application Program)**:应用程序,即使用DTP的程序。 - **RM(Resource Manager)**:资源管理器...
在传统的单体应用中,事务是数据库层面的概念,用于保证数据操作的原子性、一致性、隔离性和持久性(ACID)。而在微服务架构中,由于服务之间的边界,传统的事务管理方式不再适用,这就需要引入分布式事务的概念来...
3. 微服务架构:分布式事务可以应用于微服务架构中的服务调用、数据交换和事务管理等。 4. 分布式数据库:分布式事务可以应用于分布式数据库中的数据replication、数据合并和数据备份等。 分布式事务技术在分布式...
这种架构方式与传统的单体架构形成鲜明对比,单体架构中应用的所有功能被封装在一个单一的、大而全的应用中。微服务架构的起源与设计理念强调服务的自治、去中心化治理、以及与技术栈无关的接口。在智能家居网关系统...
在传统的单体应用中,事务管理相对简单,通常由数据库支持的ACID特性来保证。但在微服务环境下,一个业务流程往往涉及到多个服务间的交互,这就导致了分布式事务问题的出现。本文将探讨微服务架构下的分布式事务解决...
根据提供的标题、描述、标签及部分内容链接,我们可以推断出该视频全集主要围绕“微服务架构中的分布式事务解决方案”这一主题展开。接下来,我们将基于这些信息深入探讨相关的知识点。 ### 微服务架构简介 微服务...
微服务架构的应用性能监控是指在微服务架构下的应用系统中监控和优化性能的过程。微服务架构是指将一个大型应用程序拆分成多个小型、独立的服务,以提高系统的灵活性、可靠性和可扩展性。 微服务架构的优势包括: ...
2. MVC(Model-View-Controller)模式:在J2EE Web应用中,MVC模式广泛使用。模型存储应用程序数据,视图负责显示数据,控制器处理用户输入并协调模型和视图。这种模式有助于实现界面与业务逻辑的解耦。 3. EJB...
分布式事务技术是现代大型互联网应用中不可或缺的一部分,它确保了数据在多个节点间的正确性和一致性。基于HLC(Hybrid Logical Clock)的分布式事务技术架构是解决这一问题的有效方案,尤其是在高并发、大规模数据...
这本书适合DDD初学者和资深从业者,通过实际案例深入浅出地解释了如何在复杂业务场景下运用DDD和微服务来构建中台系统。作者的经验分享和创新见解,为读者提供了宝贵的实践指导。无论是对于提升个人技能还是推动企业...
在IT行业中,微服务架构是一种将单一应用程序分解为一组小型、独立的服务的开发方式,每个服务都运行在其自己的进程中,并且能独立部署。这样的架构设计带来了更好的可扩展性、容错性和灵活性,但同时也引入了一个...
在 CS 架构中,客户端需要实现绝大多数的业务逻辑和界面展示,因此客户端需要承受很大的压力,因为显示逻辑和事务处理都包含在其中,通过与数据库的交互(通常是 SQL 或存储过程的实现)来达到持久化数据,以此满足...
企业数据架构是指企业中数据的组织方式和存储结构,它决定了数据如何被收集、存储、处理和提供给不同业务应用。良好的企业数据架构能够支撑业务应用、提高数据管理的效率、确保数据安全,并提供稳定的数据服务。本篇...
在SDCC2016大数据&架构峰会上,聚焦的主题之一是"蚂蚁金服的大规模分布式事务实践和开源介绍"。这场峰会在杭州举行,聚集了众多IT领域的专家和技术爱好者,共同探讨大数据处理和复杂系统架构的最新趋势。以下是基于...
- **功能架构与应用架构**:在功能架构中,需要明确各项功能及其对应的权限。而在应用架构中,则需规划产品线、子系统以及各个应用的实现方式。例如,应用编号“102010”和应用名称“Flight.Booking.xxx”这样的命名...
分布式事务架构设计是现代互联网行业中不可或缺的一部分,尤其是在微服务架构盛行的背景下。由于单个操作可能涉及多个服务和数据库实例的协作,一致性问题变得尤为重要。CAP原理,即一致性(Consistency)、可用性...
描述部分进一步明确了文档的核心目标是介绍如何在微服务架构中解决分布式事务问题。分布式事务是指涉及两个或多个分布式数据存储单元的事务处理过程。由于微服务架构通常涉及到多个服务之间的交互,因此解决分布式...
2. **Dubbo在分布式事务中的应用**: - **TCC事务集成**:Dubbo可以通过扩展方式支持TCC型分布式事务,为开发者提供了更高级别的事务管理支持。 - **可靠消息传输**:通过Dubbo的消息服务,可以实现可靠的异步消息...