界面层 与 业务逻辑层 分离 独特的看法解决方法
界面层 与 业务逻辑层 分离 独特的看法
如何将 界面层 与 复杂的业务逻辑层 分离开来呢？或者是 分离开到一个什么样的程度算是不耦合？
请大家谈谈你们的看法~！
界面层与业务逻辑层的分离：
------解决方案--------------------
我个人认为，凡是与画面相关的操作，都是界面层，比如，画面的内容，颜色（font）设置，另外包括入力内容的有效性check等等。都是界面层。
------解决方案--------------------
分离到能各用各的就算不耦合了
------解决方案--------------------
我们一直强调的是“低耦合”，不是“不耦合”，不耦合肯定没办法运行啊
------解决方案--------------------
要做到低耦合，复杂的业务逻辑层要做到提供简单的调用接口，你可以参照一下设计模式里的“外观模式”，不管业务逻辑层多复杂，只提供简单的外观模式，界面层只和这个外观打交道
------解决方案--------------------
你可以去看一下sun核心技术丛书中的一本《j2ee核心模式》——好像是这个名字，里面有个help模式就把这个问题解决得很好。
其他语言也可以参照他的方法来解决界面和业务层之间的耦合度问题。
------解决方案--------------------
层之间接口设计问题
------解决方案--------------------
单纯泛泛而谈是不当的。
没有绝对的分层和完美的耦合的。
都是根据需求和实际。
------解决方案--------------------
------解决方案--------------------
我的做法是：
开发应用服务器，将业务逻辑全部放到中间件上去。将数据库放在中间件的后面。
然后对业务逻辑抽象出一组公用业务对象API，
可以透过TCP，SOAP方式去调用。以便支持前端的 C/S客户端，或者WebServer的网页程序(通过SOAP调用WebService方式)。
然后把界面(C/S的Form界面，或者B/S的网页界面)，作一个UI部分的整体。
实际上这里肯定包含部分预处理，尤其是C/S界面；B/S我认为只是手段比较烂(JS什么的)，只方便做发布类的事情
前台的C/S或B/S界面，就不区分UI和UI界面内的逻辑了（有时候也很难区分）。
这样大概构成了3层。实际结构如下：
-------------------------------------------------------
数据库+应用服务器+C/S Client(实际上应该是Internet Client)
+B/S WebServer + IE
-------------------------------------------------------
DB 逻辑核心 UI和弱关联的逻辑
------解决方案--------------------
数据库+应用服务器+C/S Client(实际上应该是Internet Client)
数据库+应用服务器+B/S WebServer（ASP or .NET or JSP...） + IE
------解决方案--------------------
------解决方案--------------------
------解决方案--------------------
note,学习了。
------解决方案--------------------
支持举例说明，不要搞空谈。
------解决方案--------------------
举例比较难，要在实际的项目中体会实践
------解决方案--------------------
希望你看一下MVC开发模式。在里面的介绍会非常清楚。
我以前业务和界面分离的最基本方针就是，页面里面除了数据简单验证以外，没有任何代码。所有的业务处理代码都放到业务控制层。
以前我做程序的时候，采用的方式是3层结构方式，借鉴的是EJB的架构体系。
页面只做信息交互，不做任何业务处理。
Servlet或者构建业务Bean处理每张View（页面）提出的请求，然后调用EntityBean进行数据存储和查询。业务逻辑层并不负责数据库的交互，所有的数据交互都通过实体层进行处理。
实体层主要负责数据的添加修改删除查询功能，其他的业务单据逻辑处理它并不负责。对于数据库级的错误由此层捕获，然后传递到业务逻辑层，最后传递到View层。
如果你用Java开发系统建议采用Struts和Hibernate。（Spring也可以）
如果你用C#建议你用VS.net开发。
他们都提供了业务和展现分离的基本框架。
------解决方案--------------------
cool 学习了
------解决方案--------------------
------解决方案--------------------
如何将 界面层 与 复杂的业务逻辑层 分离开来呢？或者是 分离开到一个什么样的程度算是不耦合？
请大家谈谈你们的看法~！
界面层与业务逻辑层的分离：
------解决方案--------------------
我个人认为，凡是与画面相关的操作，都是界面层，比如，画面的内容，颜色（font）设置，另外包括入力内容的有效性check等等。都是界面层。
------解决方案--------------------
分离到能各用各的就算不耦合了
------解决方案--------------------
我们一直强调的是“低耦合”，不是“不耦合”，不耦合肯定没办法运行啊
------解决方案--------------------
要做到低耦合，复杂的业务逻辑层要做到提供简单的调用接口，你可以参照一下设计模式里的“外观模式”，不管业务逻辑层多复杂，只提供简单的外观模式，界面层只和这个外观打交道
------解决方案--------------------
你可以去看一下sun核心技术丛书中的一本《j2ee核心模式》——好像是这个名字，里面有个help模式就把这个问题解决得很好。
其他语言也可以参照他的方法来解决界面和业务层之间的耦合度问题。
------解决方案--------------------
层之间接口设计问题
------解决方案--------------------
单纯泛泛而谈是不当的。
没有绝对的分层和完美的耦合的。
都是根据需求和实际。
------解决方案--------------------
------解决方案--------------------
我的做法是：
开发应用服务器，将业务逻辑全部放到中间件上去。将数据库放在中间件的后面。
然后对业务逻辑抽象出一组公用业务对象API，
可以透过TCP，SOAP方式去调用。以便支持前端的 C/S客户端，或者WebServer的网页程序(通过SOAP调用WebService方式)。
然后把界面(C/S的Form界面，或者B/S的网页界面)，作一个UI部分的整体。
实际上这里肯定包含部分预处理，尤其是C/S界面；B/S我认为只是手段比较烂(JS什么的)，只方便做发布类的事情
前台的C/S或B/S界面，就不区分UI和UI界面内的逻辑了（有时候也很难区分）。
这样大概构成了3层。实际结构如下：
-------------------------------------------------------
数据库+应用服务器+C/S Client(实际上应该是Internet Client)
+B/S WebServer + IE
-------------------------------------------------------
DB 逻辑核心 UI和弱关联的逻辑
------解决方案--------------------
数据库+应用服务器+C/S Client(实际上应该是Internet Client)
数据库+应用服务器+B/S WebServer（ASP or .NET or JSP...） + IE
------解决方案--------------------
------解决方案--------------------
------解决方案--------------------
note,学习了。
------解决方案--------------------
支持举例说明，不要搞空谈。
------解决方案--------------------
举例比较难，要在实际的项目中体会实践
------解决方案--------------------
希望你看一下MVC开发模式。在里面的介绍会非常清楚。
我以前业务和界面分离的最基本方针就是，页面里面除了数据简单验证以外，没有任何代码。所有的业务处理代码都放到业务控制层。
以前我做程序的时候，采用的方式是3层结构方式，借鉴的是EJB的架构体系。
页面只做信息交互，不做任何业务处理。
Servlet或者构建业务Bean处理每张View（页面）提出的请求，然后调用EntityBean进行数据存储和查询。业务逻辑层并不负责数据库的交互，所有的数据交互都通过实体层进行处理。
实体层主要负责数据的添加修改删除查询功能，其他的业务单据逻辑处理它并不负责。对于数据库级的错误由此层捕获，然后传递到业务逻辑层，最后传递到View层。
如果你用Java开发系统建议采用Struts和Hibernate。（Spring也可以）
如果你用C#建议你用VS.net开发。
他们都提供了业务和展现分离的基本框架。
------解决方案--------------------
cool 学习了
------解决方案--------------------
------解决方案--------------------