设计讨论:设计什么样的框架?

今天跟同事们聊到要给我们的系统设计一套框架。我问他想要个做什么的框架,他给了我一张图:

我第一感觉是:这不就是SpringMvc的Dispatch Servlet么?第二感觉是:这位同志哥好像没想清楚自己想要什么样的框架。

好的框架至少要有两个功能。

第一个功能是减少重复工作、提高开发效率。例如SpringMvc/Struts,减少了Http的重复操作;Hibernate/MyBatis,减少了JDBC操作;另外公司有些业务框架会将重复的业务功能放到框架中。这都起到了提高开发效率的作用。

第二个功能抽取、规范业务逻辑。我在公司写过账务功能的、审批功能的、任务分派的业务框架,基本都是这一类型。这类框架与其称为业务框架,不如称为业务模型。它有助于理解产品和业务逻辑,也便于维护现有功能和扩展新功能。

不过,严格的业务模型与系统优化之间往往是有冲突的。这个带过。

从提高开发效率的角度来讲,那位同志哥的框架要做的事情,基本上SpringMvc已经替我们做了。

从规范业务逻辑的角度来说,这个框架可以承担一部分责任。但是,不同的业务之间千差万别,要把它们全部装进一套处理逻辑里,有点挑战。

时间: 2024-10-26 08:00:34

设计讨论:设计什么样的框架?的相关文章

设计 REST 风格的 MVC 框架

http://www.ibm.com/developerworks/cn/java/j-lo-restmvc/ 传统的 JavaEE MVC 框架如 Struts 等都是基于 Action 设计的后缀式映射,然而,流行的 Web 趋势是 REST 风格的架构.尽管使用 Filter 或者 Apache mod_rewrite 能够通过 URL 重写实现 REST 风格的 URL,为什么不直接设计一个全新的 REST 风格的 MVC 框架呢? 本文将讲述如何从头设计一个基于 REST 风格的 Ja

设计讨论:依赖倒置,与 “I'll call you”

问题来自于我和同事在一个跨系统交互设计上的分歧. 同事的设计,基本上是这样的: 这种设计很常见,其基本思路就是:服务端接口需要什么数据,客户端就传入什么数据.这种设计的优点在于简单:开发简单,交互简单.但是它的缺点也很明显:扩展性低.一旦服务端对某个业务中的业务-数据依赖关心进行了修改,则客户端很可能也要跟着修改.例如,如果系统B中,完成业务B1需要的数据不再是D1而是D3,则不光系统B要改,系统A也要改.如果还有系统C/D/E/F也调用了这个接口,那么这些系统都面临着修改代码的风险. 实际上,

如何使用JAVA设计在线设计管理系统的代码详解

一,关于我们我是专业从事于定做计算机相关毕业设计,拥有专业的写手团队和严格的保密制度.我们的工程师们在软件工程开发与设计的各个领域积累了丰富的经验,保证服务水平.近两年,每个毕业季都帮助至少50位以上的计算机专业同学通过了毕业答辩,也是一件很开心的事情.每每看到他们来找我做毕业设计就像抓住了救命稻草一样,那种充满期待,和无助的感觉,也让我觉得把毕业设计给他们做好,服务好每一位同学是我义不容辞的责任,同学通过后.那种欢喜,我也是感同身受. 联系我们:.扣.扣.号(幺零三贰三七幺贰幺) 对于大多数的

面向对象设计的设计原则

只有深刻理解审计原则,自然而然就能写出设计模式. 通过refactor(重构)得到设计模式.--现在还是不是很理解 1.针对接口编程,而不是针对实现编程 2.优先使用对象组合,而不是类继承 3.封装变化点 1.针对接口编程,而不是针对实现编程 客户(程序)无需知道所使用对象的特定类型,只需要知道对象拥有客户所期望的接口. 2.优先使用对象组合,而不是类继承 类继承通常为"白箱复用",对象组合通常为"黑箱复用".继承在某种程度上破坏了封装性,子类父类耦合度高:而对象组

数字化设计界面设计趋势

数字化设计,尤其是界面设计,新趋势之一就是简单.其实微软早在2007年可能已经开始进行对简单界面的追求了,当时他们推出的Zune播放器拥有优美的排版界面.尽管该产品的有些失败,但其UI进行了改进并且应用到Windows Phone和Windows 8界面设计里.另一方面iOS上在大量逼真的纹理和深度的基础上,加上渐变.光泽的风格效果和阴影效果,但是我们开始看到越来越多适用于所有平台的北京UI设计应用程序采用了更简约的方式. 在这篇文章中,我们配合一些漂亮的设计说明这一趋势.这些照片来自Dribb

这几天设计讨论的一点心得

这几天和同事讨论新项目.系统的设计方案.理越辩越明,有一些以前模模糊糊的想法.概念,都随着讨论,有时甚至是争论而变得清晰明确. 一是服务接口的幂等性. 以前做服务接口,都没考虑过这个问题.这次静下来想了想,觉得服务接口必须具备幂等性才对. 也就是说,在没有其它操作的情况下,对同一个服务接口无论调用多少次,系统状态以及返回结果都应当是一样的. 如果不是这样,前后脚两个操作,一个告诉我说OK了,另一个告诉我说出异常了.这算什么鬼=.= 就一般的增删改查来说,删改查基本上是很容易支持幂等性,甚至天生幂

用户日志的收集传输存储架构设计讨论

上一篇我们分析了目前主流的用户日志采集方法:http://blog.csdn.net/tonylee0329/article/details/43705065, 本篇我们将要讨论是如何将这些日志传输到我们的存储系统以便于后续处理分析,会结合离线以及实时两条线来探讨. 目前我们采取的方案是这样的: 这样架构的考虑点: 1.先说离线,从日志传输和容错方面而言,rsync无疑是最好的方案,它基于日志的内容做增量传输,快速稳定而且高效 2.实时的这条路,前面的Flume和Kafka可替代的开源工具(如S

Java EE 架构设计——基于okhttp3 的网络框架设计

转载请注明出处:http://blog.csdn.net/smartbetter/article/details/77893903 本篇文章带大家设计一套满意业务需求.代码健壮高效(高内聚低耦合)并且可拓展的网络框架.以最新的okhttp3为基础设计出高效可靠的网络缓存.多线程文件下载等架构模块.从此不局限于使用别人的框架,而步入了设计框架,让自己可以走的更远,我觉得这才是一名合格开发者所应该具备的能力.在开发中,选择一个开源框架的标准有很多,例如学习成本.文档是否齐全.github星数量.现在

领域驱动设计案例之领域层框架搭建

根据前面对领域驱动设计概念以及一些最佳实践的理解,领域模型是系统最核心的部分,我们还是采用前面销售订单的例子,这个案例系统的核心构建就从领域层开始.领域层框架搭建主要完成两个任务: 1.领域模型的建立,聚合与聚合根的确定,关系的确定. 2.建立支持DDD理论的领域层接口. 这里先上代码图,再详细讲每个部分的主要功能: 1.Model中主要确定了领域对象,聚合与聚合根,关联关系等,我们这里采用的是EF 的Model First建模,你也可以采取Code First.如下图: 2.Aggreate中