关于WEB三层架构的思考

1.MVC设计思想

MVC程序设计思想是眼下比較流行的WEB开发的模式，当中，M（model）是模型。即JavaBean，用来封装和保存数据；V（view）是视图，即JSP。用来显示内容；C（controller）是控制器，即servlet，用来处理业务逻辑。大致流程是这种：编写一个JSP页面用来获取信息（如登录页面获取用户登录名、password）。并将信息封装到JavaBean中，提交到server端由WEB容器将数据封装成request请求。交给servlet来处理。

servlet从请求中获取用户信息到数据库中查询。并返回对应的结果（登录成功或失败），再将结果封装成response响应发送给client浏览器，浏览器依据response头和其它信息进行对应的显示。

如图：

MVC设计思想将数据封装、显示和业务处理分开，JavaBean、JSP和servlet都仅仅做自己最擅长的事，模块化使整个过程更加清晰，符合Java低耦合的思想，提高代码的灵活性，易于扩展和维护。

详细分工例如以下图：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMTk5MQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

2.WEB三层架构

从上图能够看出。数据訪问层中JavaBean既要存储数据内容又要获取数据内容，这违背了单一职责原则。

我们希望JavaBean仅仅是单纯的用来封装数据。其它的交给别人来做，因此在WEB开发中，将数据訪问层进一步细化。用JavaBean来封装数据，而数据是持久化存储在数据库中（也能够是XML等文件里）。通过DAO（Data
Access Object）数据訪问对象来查询数据库（或解析XML文件等）。有时，视图层不一定仅仅有JSP。，有些内容须要通过servlet技术显示，如登录页面的验证码。当业务逻辑过多时，业务逻辑层就会显得特别臃肿。不利于扩展和维护。这时能够将业务功能抽象成接口，详细功能由子类实现。

那么问题来了，怎么知道哪个类去处理哪个业务逻辑呢？解决方式是定义一个核心servlet。用来接收全部的client请求，通过推断将请求交给相应的业务处理子类去处理。这里可參见Struts2的实现原理。这里不再赘述。

这样，业务逻辑层就分成了两部分：用于显示的servlet和分发业务的servlet。例如以下图：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMTk5MQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

3.真实案例

然而。真正开发中，以上并非终于的解决方式。

拿一个实际案例来说。开发一个简单的B2C电子交易平台系统（功能包含：用户登录、注冊、邮箱验证、查看商品、加入商品、购物车、下单、在线支付等），包结构例如以下：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvcXFfMTk5MQ==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

~~未完待续~~

以上均为个人观点。如有疑问。欢迎交流~~