Architecture

我真失望！ 看这里： http://boards.developerforce.com/t5/AppExchange-Directory-Packaging/How-to-enable-subscriber-specific-settings-in-a-managed-package/td-p/261763 Re: How to enable subscriber-specific settings in a managed package? I don’t think there’s a way to collect the info during install. It would have to be a post-installation step. These instructions should be in your Customization/Installation guide. The place to store this type of information is in a Custom Settings record …

SalesForce: 让subscriber在安装Package时指定一些参数？ 不可能！ Read More »

SalesForce中，　一个Developer Edition只能有一个Managed Package (今天是2011-3-28) 如果要开发多个Managed Package，就得建多个Developer Edition. 如果多个Package之间有代码共享，那就很．．．．．． 很多人都在抱怨：　 　 http://success.salesforce.com/ideaView?id=08730000000BqDaAAK

看下面： https://cwiki.apache.org/S2PLUGINS/spring-webflow-plugin.html 这样的话Struts2里也可以比较方便地构建 Wizard了

MVP可以跟MVC对照起来看。和MVC一样，MVP的M就是 Model, V就是View，而P，则代表Presenter，它与Controller有点相似。 不同的是，在MVC中V会直接展现M，而在MVP中V会把所有的任务都委托给P。V和P会互相持有reference，因此可以互相调用。这也暗示着V肯定是一个富的客户端。 维基百科的介绍是： In this formulation, when a user triggers an event method of the view, it does nothing but invoke a method of the presenter which has no parameters and no return value. The presenter then retrieves data from the view through methods defined by the view interface. Finally, the presenter then …

学到了一个新名词：MVP模式 Read More »

摘自 Struts2 in Action A framework tries to make generalizations about the common tasks and workflow of a specific domain.

答: 影响了下层模块的可重用性。由于下层依赖上层的某个模块，当上层的另一个模块需要调用该下层模块时，那就会发现这个下层无法直接调用。 举个例子。比如 某个Service模块需要读取“操作者”以判断权限。第一次写代码时，为了贪图方便，就直接在Service里读取 Session.getUser()获得“操作者” 。后来来了新需求，某个Web服务也要调用这个Service，那这样就会出问题了。

比如说， 人和兽都是动物，业务规则是：直立者即人，爬行者为兽。 那么 在“动物”表中， 除了要有 “行走方式” 这个字段，要不要再搞一个 “是人是兽” 字段？ 隐方：不必了。通过站立方式已经可以推导出是人是兽了， 再搞一个字段就是冗余了，众所周知，冗余有很多坏处。 显方：我觉得应该搞一个“是人是兽”的字段。先不说冗余的问题，先说搞一个这样的字段有哪些好处。    1. 最重要的一点，是可以帮助业务逻辑之间解耦，降低系统复杂度。  比如说，系统里判断一个动物能否说话时，先要判断这个动物是人还是兽，而要判断动物是人还是兽，要先判断它的行走方式是否为直立。 这样的话，“能否说话” 就依赖了 “是否直立行走”，如果这种依赖关系多了，这些关系就会在系统中形成一个网状结构，很复杂。而如果我们显式地搞一个 “是人是兽” 的 Mediator，网状结构就可以退化成星形结构，这样可以增强系统的可维护性。    2. 业务逻辑之间解耦后，还可以减少公司里业务专家的压力。很多程序员，尤其是新来的五谷不分的程序员，并不知道直立的就是人，趴着的就是兽。要了解这一点，他们就得去问业务专家，即老工程师或者产品经理，这个代价可大可小。他也可以去查文档，但按我们的现状，文档未必完整，而且篇幅巨大，查起来也非常费劲。 隐方：对你的第二点我很赞同，但关于第一点，我觉得还是设计技巧的问题。 你在业务层写一个接口用于判断“是人是兽”，不就可以了吗？而且这样还可以封装判断的细节，当判断规则改变时，接口的调用者可以不必改写代码。 显方：这么看来至少你赞成搞一个“显式”的接口了，只不过是放在业务层；这样既可以实现业务逻辑的解耦，又可以避免数据库中的冗余。 隐方：是啊，很完美吧？ 显方：但你的想法 需要一个大家定一个规矩：即所有人都必须通过个接口来进行人兽判断。这在代码不多、并且软件复用思想深入人心的小型团队里倒是很适用，因为这个规矩很容易执行；但在大型团队里，这个规矩很难执行；因为 很多人对业务层的重用并没有什么概念，他们会直接绕道去找数据库；而且 即使他们愿意重用业务接口，在项目紧张时也懒得去找相应的接口规格，因为他们根本不知道这个接口是否存在，也不知道应该去找谁问这个问题。 隐方：这是另外一个问题了，主要跟软件过程有关系，或者可以借鉴SOA实践中的一些思想，我们另开一个话题再聊吧。

比如说，要判断本公司某员工是否为中国人，在系统中可以分别通过调用两种接口来获取结果：   a.护照上写的是中国人 => 此人是中国人   b.工作证上“国籍”一栏填了“中国” => 此人是中国人 这两个逻辑冗余了，因为它们可以解决同一个问题，在现实世界里，这是很现实的事；但在IT系统中，不应该让这两种逻辑同时存在。也就是说，要判断一个人是否为中国人，只能去查他的护照，不准通过其它途径来判断。 为什么要这样？ 因为如果不这样的话， 两条冗余规则中一旦改了一条，除了该规则自己的调用者受影响之外，另一条规则的调用者可能也会有问题。 比如说，如果上面的规则b改成 ［ 工作证上“国籍”一栏填了“中国” 或 "香港" =》 此人是中国人］，那么我们除了要改一下b接口 and/or 它的调用者，还要注意一下 规则a  and/or 它的调用者： 香港人的护照也是中国护照吗？ 是，则万事大吉；如果不是，那就要把a接口改一下，或者把a接口的调用者都改一下。

很多需求文档过于简单，一个功能点只是一个谓词，而没有足够的发散。比如 "if A then B"，那么 "if not A "该怎么办呢？ 文档里没写，开发暂时悬搁。 需求分析员也是人，他可能不喜欢发散性思维，也可能太多发散让他很疲惫；反正最终结果就是需求发散不足，即完备性不足；所以我们就应该让机器来替它发散。这种机器就是一种软件，它读取简单的判断句作为输入，然后对这句话的各点进行各种维度的发散，导出各种各样的"what if", 以实现需求的完备性。 比如 if A  –> if not A， 就是一个例子。 那么可以在哪些维度上发散呢？ 发散时可否可以利用相关上下文？ 这种软件是否具有自适应的智能性？最后一点，这种软件如何实现？ 1.发散维度   a. 布尔发散。 A -> Not A, A & B -> A || B 等等   b. 数量发散。 A 关联 B。是一对多，多对一，还是多对多呢？   c. 生命周期发散。比如 A关联或者依赖B。那么A被增删改时，B应该怎么办？反之如何？   c. … 2.相关上下文   …

我有个想法：做一个提高需求完备性的软件 Read More »

以前一直有就这种想法，今天发现“Enterprise SOA”这本书中明确地把它提出来了： “面向对象强制性封装数据和功能，而面向服务通常认为数据和功能是分开的” 这让人联想起 贫血模型与充血模型旷日持久的争论…… 还有， "对象的粒度一般比较小，这会在分布式系统中导致很多远程调用"