2007年02月
业务基础软件平台是指以业务导向和驱动的、可快速构建应用软件的软件平台。面临中国软件需求旺盛，不断成长，但项目失败多，软件企业做不大，不赢利，用户不满意的局面，我们首先应该选择一条打破这个局面的一条路，在市场总额不变的情况下，在外国基础软件做主导的局面下，通过软件企业自身的层次划分，有做软件个性化实施，有做业务基础软件研发的，通过产业分工，形成新的产业链，通过产业链条上的分工合作，提高开发效率，实现在总额不变的情况下来实现赢利，实现项目成功多、用户满意、软件企业赢利的共同局面。阅读全文>
发表于 @ 2007年02月09日 14:21:00|评论(loading...)|编辑
1983年12月12日，出生于一个普通的工人家庭，1-5岁不知道自己是谁，干了什么，6岁被爸爸妈妈强行扭送厂办小学1年级2班，在“我去上学校，天天不迟到，小鸟送，早早早，你为什么背上小书包”的儿歌中开始了读书生涯……阅读全文>
发表于 @ 2007年02月09日 14:12:00|评论(loading...)|编辑
软件的智能和记忆功能1.用户登录界面最好有用户名和ID的记忆，焦点直接定位到密码输入框2.单据录入界面最好有保存和载入默认值的功能3.单据搜索界面可以保存用户自定义的各种搜索条件组合4.用户调整过的GRID的列宽，窗口的位置可以自动记忆5.系统可以根据用户的使用频度对相关功能进行自动的优先级排序6.系统能够记忆不同用户的使用偏好，使用系统的固有模式和常用的自定义设置。阅读全文>
发表于 @ 2007年02月09日 09:45:00|评论(loading...)|编辑
一、全心投入工作（work harder at what you do）：当你工作时，一定要全心投入，不要浪费时间，不要把工作场所当成社交场合。二、工作步调快（work faster）：养成一种紧迫感，一次专心做一件事，并且用最快的速度完成，之后，立刻进入下一件工作。阅读全文>
发表于 @ 2007年02月09日 09:38:00|评论(loading...)|编辑
在设计分布式应用程序时需要确定如何访问和表示与该应用程序相关联的业务数据。本文提供一些指导原则以帮助您选择公开数据、保持数据和在应用程序的层间传递数据的最佳方式阅读全文>
发表于 @ 2007年02月09日 09:34:00|评论(loading...)|编辑
如果想这样，就得给存储过程建立元数据，而不是给表建立元数据，表对应的是Object(实际物体，订单啦，产品啦)，而存储过程对应的是Action（例如增加或者取消一个订单）或者Service(例如根据某个条件来生成一个DataView)的数据层实现，当然有人说了“随着在存储过程中实现的业务逻辑的增多，存储过程可以简化维护带来的优势会逐渐减弱”，可是那也比纯用Opath这类更高层次的语言来实现数据访问有优势吧，再说了存储过程只封装细粒度的业务逻辑，返回简单处理后的数据，然后由数据层经过复杂处理才提供给业务层的。阅读全文>
发表于 @ 2007年02月09日 09:30:00|评论(loading...)|编辑
因为以业务架构平台为基础的开发方式主要以建立模型为主，而以业务架构平台为基础的模型不同于以往的计算模型，其建立的模型首先是业务模型，而不是为编程服务的程序结构模型。业务架构平台领域的各类产品，如业务规则、工作流、业务智能、业务建模、业务引擎、决策分析、业务集成等，也必然被融合到业务架构平台这一层级。不仅如此，业务架构平台还能为企业信息化建设提供好的解决方案，企业利用业务架构平台构建信息系统一方面是零风险（或低风险），也就是说风险很低，在实施的过程中不必有太多的后顾之忧；阅读全文>
发表于 @ 2007年02月09日 09:26:00|评论(loading...)|编辑
特别是JBoss，更加积极推出JBoss Seam框架，希望确立以JSF＋EJB3的架构树立Java开发的标准，用以取代Struts/Spring/Hibernate的流行组合，因而开启了EJB3和Spring 正面交锋的战争。这几年除了Spring框架自身不断完善和延伸到传统应用领域，围绕在Spring周围的第三方框架也是越来越丰富，EJB3在annotation方面有些独到的优势，在一些传统领域，还领先spring，但是总体来说，EJB3为核心的J2EE5.0规范很难和Spring现在的2.0相匹敌，更何况Java的主力Vendor早已醉翁之意不在这里了，单凭JBoss的Seam，难以战胜spring。阅读全文>
发表于 @ 2007年02月09日 09:15:00|评论(loading...)|编辑
一、Hibernate是JDBC 的轻量级的对象封装，它是一个独立的对象持久层框架，和App Server，和EJB没有什么必然的联系。二、Hibernate是一个和JDBC密切关联的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有一定的关系，但是和使用它的Java程序，和App Server没有任何关系，也不存在兼容性问题。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的替代者出现的，而不是Entity Bean的替代者出现的，让我再列一次我已经列n次的框架结构：阅读全文>
发表于 @ 2007年02月09日 09:07:00|评论(loading...)|编辑
例如，让WEB服务器负责提供页面，应用服务器处理应用逻辑，而数据库服务器提供数据库服务。在JDBC出现的初期，JDBC-ODBC桥显然是非常有实用意义的，通过JDBC-ODBC桥，开发人员可以使用JDBC来存取ODBC数据源。JDBC本地驱动程序桥提供了一种JDBC接口，它建立在本地数据库驱动程序的顶层，而不需要使用ODBC。JDBC驱动程序将对数据库的API从标准的JDBC调用转换为本地调用。JDBC网络桥驱动程序不再需要客户端数据库驱动程序。要在N-层结构中应用，一个更好的做法是编写一个EJB，让它包含存取代码并提供一个对客户端具有数据库独立性的服务。阅读全文>
发表于 @ 2007年02月09日 08:43:00|评论(loading...)|编辑
从分层角度来看，现在三层架构：表现层、业务层和持久层，三个层次应该分割明显，职责分明：持久层职责持久化保存业务模型对象，业务层对持久层的调用只是帮助我们激活曾经委托其保管的对象，所以，不能因为持久层是保管者，我们就以其为核心围绕其编程，除了要求其归还模型对象外，还要求其做其做复杂的业务组合。上面是谈过分依赖持久层的一个现象，还有一个正好相反现象，持久层散发出来，开始挤占业务层，腐蚀业务层，整个业务层到处看见的是数据表的影子（包括数据表的字段），而不是业务对象。阅读全文>
发表于 @ 2007年02月09日 08:36:00|评论(loading...)|编辑
插件系统概述。插件由其他开发人员根据系统预定的接口编写的扩展功能，实际上就是系统的扩展功能模块。插件必须实现扩展点，以此插入到系统中，新增扩展点并不是必须的，但只有新增了扩展点的插件才可以被别人扩展。在系统装载期，绑定到系统中的接口都是代理对象，当外界需要与插件交互，例如显示、运行某个方法的时候，由代理来自动装载真实的插件，然后将调用委派给插件来响应。微内核中的插件关系由插件自身来维持，插件实现的扩展决定了它和父插件之间的交互关系，新增的扩展点决定了它和将来在它基础上扩展的插件交互的模式。阅读全文>
发表于 @ 2007年02月07日 12:28:00|评论(loading...)|编辑
将软件模块比作积木，我们程序员就是玩积木的人了。在插件系统中，插件就是积木。粗略地可以将程序员分成两类：做积木、与玩积木的人。做积木的人指的就是那些自己写控件、插件的人，玩积木的人指的就是将各种各样控件或插件组装成系统的人。我们很难说做积木与玩积木的人哪一个水平高，因为需要的是两种不同的能力。做积木的人需要对底层计算机技术有深刻的了解，而玩积木的人则需要对业务、用户需求和整体框架有清楚的认识。我们不能仅仅按照做积木和玩积木两种类型来区分技术含量，不同的工作对技术的侧重点不一样。阅读全文>
发表于 @ 2007年02月07日 12:27:00|评论(loading...)|编辑
业务逻辑在一个系统中可放的地方很多，有的人选择放在存储过程中，有的人会选择放在业务组件中，这些方式都可以进行业务逻辑的判断。就像在设计的过程中，很多人会将进行条件选择语句封装到不同的类的重构，以满足设计中的”开－闭“原则，这样做有他的道理。但并不是说以后就不用条件转移语句了，要不开发语言怎么会支持条件转移语法呢。我们要根据具体的情况选择是否重构，比如我们只需要创建一个对象，如果进行重构，试想得建多少的类啊，维护起来头不够大啊。阅读全文>
发表于 @ 2007年02月07日 10:50:00|评论(loading...)|编辑
数据传到了界面，界面是否有需要优化的地方呢？如果一个界面打开后所需时间较长，有可能是初始化的工作量太多，是否可以考虑减少在窗体加载时的初始化工作，而放到窗体显示后呢？阅读全文>
发表于 @ 2007年02月07日 10:48:00|评论(loading...)|编辑
流行FrameWork整合之Spring—— IoC反向控制篇 阅读全文>
发表于 @ 2007年02月07日 10:26:00|评论(loading...)|编辑
EJB(2.X-3.0)、Hibernate、Spring：剖析、批判和展望阅读全文>
发表于 @ 2007年02月06日 08:54:00|评论(loading...)|编辑