摘要：
这段时间在编写基于CodeDom动太操作对象属性的组件，为了证明一下效率于是和反射操作进行简单的测试比较。测试主要分为两部分：属性设置和属性获取。分别测试了硬编码、CodeDom动态调和反射三种情况比较。 属性设置测试： 测试代码： Console.SetOut(new System.IO.Strea... 阅读全文
2006年10月13日
2006年10月10日
摘要：
在实际开发过程中需要经常编写Entity和UI数据交换相关代码，虽然代码并不复杂但确是一个非常烦琐的事情。为了解决这一问题所以编写一个数据绑定组件来处理这方面的事情，即减少代码编写的时也提高代码维护的方便性。
组件主要有三个对象
EntityDataBinder
数据绑定对象，要用于Entity数据输出UI和UI导入数据给Entity。
IPropertyMapper
成员映射描述，用于表示Entity的某个数据成员对应着相关对象的成员属性；对象的Changer属性用于描述数据输入和输入的转换方式。
IChanger
数据转换对象，用于隔离数据输入和输出转换的实现，可以方便开发人员实现自己的转换类型方式。组件实现了基础的转换对象Changer、ToStringFormat和DateTimeToString等。
阅读全文
2006年10月8日
摘要：
遇到了个非常头痛的问题，通过打开窗体的方式来显示页面后不能访问Session值。可能是IIS服务把新开的窗体当作一个新的连接，重新分配Session会话。出现这情况是使用了一种比较特别的打开窗体方式正好项目碰上了。发生问题的打开窗体方式:先ShowModalDialog一个模式窗体，然后在模式窗体再Open一个窗体，这时候打开的页面就不能访问之前面设置的Session值。如果统一用S... 阅读全文
摘要：
今天碰到了通过Page.Request[XXX]获取不了页面元素提交值问题；令我头痛的是控件在某些页面可以有些不可以。分析了很久都找不到原因，所有Input Type定义都是一样但就是有些元素在某些页面上获取不了提交值。经过很长时间的查看发现不能提交值元素的顶层元素disabled属性而导致的。就是这点问题搞了我差不多一个时候，还跟踪调试控件的ViewState加载和读取过程是否在存... 阅读全文
2006年10月7日
摘要：
/// /// 数据查询业务逻辑基础类 /// /// 条件类型 /// 实体对象类型 public abstract class QueryLogicAdapter : SingleLogicAdapter where T:IFilter,new() { #region IQueryLogic 成员 pr... 阅读全文
摘要：
/// /// 数据模型操作基础类 /// /// 模型类型 /// 主索引类型 public abstract class ModelLogicAdapter : System.MarshalByRefObject, IModelLogic where T:new() { #region IModelLogic 成员 ... 阅读全文
2006年9月26日
摘要：
基于远程代理的对象调用，成员的操作对性能影响还是比较大的。从2和1测试用例对比可以看到，只是多了一个成员的调用并发率竟然能相差这么大。因此在调用远程对象时最好是基于无状态方法的调用，这样可以减少远程对象的访问次数，从而获取性能上的提高。
缓存的利用也是一个很重要的因素，这样可以避免远对象创建过程中带来的损耗问题。直接由RemotingConfiguration配置代理的对象内部已经提供这处机制，如果代理对象是通过另一个代理创建时缓存就变得很重要从2和5的测试图可以看到差别。多层代理对象的创建对性能的影响比较严重，因此遇到这情况要特别注意。 阅读全文
2006年9月25日
摘要：
测试环境： Server: P4 2.4G 1G 内存 Client: P4 1.8G 1G 内存 Client使用ASP.NET 2.0创建远程对象；然后通过ACT对Clinet进行测试。具体测试情况如下： 概述: 摘要 (1) ... 阅读全文
2006年9月20日
摘要：
泛型有什么好处就这里就不介绍，因为网上有更多详尽的资料。下面看一下相关情况的类结构图： 以上是制定业务处理的基础规则结构图，里面分别描述了基于泛型的查询基础规则（QueryAdapterAs）和不基于泛型的查询基础规则（QueryAdapter）;两者完成的功能都是对IFilter描述信息进行数据查询。 使用代码： QueryAdapter query = new QueryAdapter();... 阅读全文
2006年9月18日
摘要：
前两天同事讲解他编写的快速开发模型，他把现实中的不同功能的ASP.NET页面归类，然后根据不同情况实现了相关的模板类；当你需要某此功能时从相关模板派生出来然后重写某些成员很快就能完成（如某行为的Button,或数据编辑Entity来源）。在他演视时并没有看到他编写业务逻辑，于是就好怪地问他是如何处理的；原来在每个类别的页面模板内部都捆绑数据处理功能，他试图在模板类中完成所有数据处理的情况和相关业务逻辑规则。当然这情况我是非常反对的，因为随着业务的变更模板类就会变得臃肿难以维护，最后可能出现更糟的事情!当我提的一大堆面对的问题后确被一个很直接的答案了结了“快速开发”，的确真的很方便对于他描述的例子，我也不能否认！
其实同事的方案是很好的，能使开发人员够遵循一个规则并进行快速开发。只是有一点我是很不认同的就是UI、BLL和DAL捆绑在一起，集中捆绑对代码的修改和维护都是致命的；何况修改和维护的时间往往比开发的时间要长，相应的成本就更高!除非能保证代码能适应所有情况，这显然是不太可能...
阅读全文
