RAD外层框架应该具备的内容

 　 整个RAD工具应该包括对象建模，流程建模，业务规则建模和界面建模几部分的内容。因此RAD工具的底层首先应该实现很多基础的内容，否则整个RAD架构本身就是不健壮的。

　　现在大家都热衷分层，一个分布式系统是应该适当分层，但要适度。如果分层太多把系统搞得太复杂反而是适得其反，因此我一直的一个观点是架构本身可以具备复杂性，但复杂性是内聚的，不应该暴露给最终的开发人员和使用者。类似于分层，搞得一个简单的功能都要涉及到5,6个甚至更多的类需要和修改，显然对开发效率是有影响的，而且分层太多反而是系统不稳定，出了异常跟踪起来也困难。  
 
1.数据持久层选择：这里需要引入相关的O/R Mapping组件。现在用过的感觉XPO比较好，但是商业化的软件。如果使用NHibernate,Castle或Gentle，则还需要处理大量的配置信息，而这些配置信息到了RAD平台下都需要系统自动的去处理和生成。其实不管用哪种组件，对于数据集的绑定上面始终是无法提供很好的支持的。而使用DataSet或Typed DataSet则基本无此问题，但需要自己来实现一些O/R Mapping的功能。  
2.异常日志的处理：这应该是系统最基本的一个功能，在这里不推荐使用App Block或其它开源组件了。这块可以根据RAD平台的自身业务需要自己写代码来实现。主要是要明确具体的业务需求，如方面问题的跟踪和Debug，异常能够记录下来，用户相关操作能够记录下来，发生异常时候给用户抛出友好提示但相关实际的错误堆栈又能够记录。这块的实现切记是简单好用，搞得太复杂了反而不好用，而且往往需要大量的配置信息。mda.com  
3.分布式的安全性问题：分布式的安全性主要需要考虑暴露的远程服务接口的安全性，另外就是数据传输过程中的安全性。基本就是这两个大问题，对于Web Service可以采用增加Soap Header来实现验证或采用WSE。对于Remoting安全性可以考虑增加自定义Sink的方式，以Addin插件的方式加入，这样可配置性和扩展性都很强，这块在Sharp Develop IDE和Indigo中有很多可借鉴内容。  
用户可以选择具体分布式的实现方式，系统应该通过用户选择的方式自动生成相关的服务接口类和服务代理类。所以这里对于Remoting+IIS来实现分布式是最简单的一种方式，只需要配置客户端和服务器端的两个Xml文件即可以实现分布式。因此这里的分布式实现将转换为一个部署问题，用户在RAD建模完成后通过一个发布功能即可以将系统发布为一个分布式的系统。