应用系统的核心 应该是 业务逻辑层。
它本身还可以分类:
1,生命周期控制及容器。 该部分除了可以控制业务层的组件的生命周期。同样还可以控制 其他模块的生命周期,或者其它模块中模块级生命控制容器的控制。(应用服务器中,ejb标准中的生命周期控制部分。P.S.至少还可以分为应用级别与会话级别两类)
2,业务逻辑。完成需要的业务需要的主体逻辑单位。(ejb中的会话bean)
3,业务流程逻辑。根据业务的流程,确定业务逻辑单位间的流程关系。(工作流)
当系统不大时 业务层 本身就被分化 到其他模块中。比如:struts的controller可以承担“业务流程逻辑”的能力。
在小的web系统中 也经常可以用 application session 这样的web内置生命周期范围容器 承担 生命周期控制。
而在比较大的系统中 比如使用应用服务器的系统 可能就将生命周期管理 交给 服务器管理了。
现在的系统,就国内而言。一般连使用应用服务器的级别都没有达到,大部分只用web服务器。所以,更常见的系统使用 appliction session这样的范围对象充当 “生命控制及容器” 。
所以,一般的系统框架能够很好的抽象 “业务逻辑” 并,能够接受 session的来数据,即可,较为大的提高开发效率了。但,如果要作的比较完美,要么用ejb以及应用服务器,要么至少自己写一个session级别的 生命控制容器(应用级别的可以用spring 来管理)。
它本身还可以分类:
1,生命周期控制及容器。 该部分除了可以控制业务层的组件的生命周期。同样还可以控制 其他模块的生命周期,或者其它模块中模块级生命控制容器的控制。(应用服务器中,ejb标准中的生命周期控制部分。P.S.至少还可以分为应用级别与会话级别两类)
2,业务逻辑。完成需要的业务需要的主体逻辑单位。(ejb中的会话bean)
3,业务流程逻辑。根据业务的流程,确定业务逻辑单位间的流程关系。(工作流)
当系统不大时 业务层 本身就被分化 到其他模块中。比如:struts的controller可以承担“业务流程逻辑”的能力。
在小的web系统中 也经常可以用 application session 这样的web内置生命周期范围容器 承担 生命周期控制。
而在比较大的系统中 比如使用应用服务器的系统 可能就将生命周期管理 交给 服务器管理了。
现在的系统,就国内而言。一般连使用应用服务器的级别都没有达到,大部分只用web服务器。所以,更常见的系统使用 appliction session这样的范围对象充当 “生命控制及容器” 。
所以,一般的系统框架能够很好的抽象 “业务逻辑” 并,能够接受 session的来数据,即可,较为大的提高开发效率了。但,如果要作的比较完美,要么用ejb以及应用服务器,要么至少自己写一个session级别的 生命控制容器(应用级别的可以用spring 来管理)。