对SpringMVC的一点看法

最新推荐文章于 2025-03-02 21:37:01 发布

mengrunancy

最新推荐文章于 2025-03-02 21:37:01 发布

阅读量378

点赞数

分类专栏：后台文章标签： MVC

本文链接：https://blog.csdn.net/masko123/article/details/54173837

版权

后台专栏收录该内容

7 篇文章

订阅专栏

本文详细阐述了B/S架构的三层结构，包括显示层、业务层和数据访问层的作用及其实现方式，并介绍了这种分层结构带来的诸多优势。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

在对某项目模块进行开发时，理论上需要创建相应的action、dao、service、entity和util包以及对应的java文件，而真实情况仅用到其中的某几个而已，必不可少的部分就是action、dao、service，这也是MVC分层结构的集中体现。

典型的B/S开发，三层结构在物理上分为：显示层、业务层、数据层访问层。

之所以会有三层的考量，主要是为了隔离和解耦(降低代码耦合度)

三层结构的优点显而易见：

1、开发人员可以只关注整个结构中的其中某一层；

2、可替代性：可以很容易的用新的实现来替换原有层次的实现；

3、解耦：可以降低层与层之间的依赖；

4、可标准化：有利于标准化；

5、可复用性：利于各层逻辑的复用。

6、清晰度：结构更加的明确

7、可维护性：在后期维护的时候，极大地降低了维护成本和维护时间
三条原则：

1.数据层访问层只提供基本的数据访问，不包含任何业务相关的逻辑处理(dao)

2.显示层只负责显示和采集用户操作，不包含任何的业务相关的逻辑处理；(action)

    3. 业务层负责处理业务逻辑。通过获取显示层传来的操作指定，决定执行业务逻辑，在需要访问数据源的时候直
   接交给数据层访问层处理。处理完成后，返回必要数据给显示层(service)

    当显示层往业务层传递的数据过多时，可以将参数封装为一个javabean，比如
    javabean需关注的部分：
    1.注解 2.calss类内部的成员变量 3.get、set方法

package com.ces.component.archive.entity.fonds;
import javax.persistence.Entity;
import javax.persistence.Table;
import com.ces.xarch.core.entity.StringIDEntity;

@Entity
@Table(name = "T_ARCHIVE_FONDS_CODE")//采用注解形式，有时传递的参数并非来源于一张物理表，@Table可以不要
public class FondsCode extends StringIDEntity{
    private static final long serialVersionUID = 1L
       /** 名称 **/
       private String name;
    
       /** 代码 **/
       private String code;
    
      /** 简称 **/
       private String shortName;
     
        public String getName() {
		return name;
	}

	public void setName(String name) {
		this.name = name;
	}
	public String getCode() {
		return code;
	}
	public void setCode(String code) {
		this.code = code;
	}
   public String getShortName() {
		return shortName;
	}
    public void setShortName(String shortName) {
		this.shortName = shortName;
	}






}