将通用进行到底。另类程序架构。
通用，“懒人”的方法。
我承认我很懒，所以我寻求通用的方法。如果一切都是通用的该多好呀，因为有通用的东东就不需要在写代码了，只需要再调用的时候传几个参数，或者改改属性就可以了。
其实通用的东东有很多，.net framework自带的就有很多，最典型的就是DataGrid了。
编写简单的几行语句就可以把表里面的数据显示出来，再也不用去考虑什么TR TD了。
但是它的通用牺牲了一些其他方面，比如分页功能，为了适用所有的情况，不得不以牺牲性能作为代价。数据多了，就会占用比较多的内存，造成访问速度下降。
当然我这里并不想讨论DataGrid如何如何，我只是想说明，我做的东东不追求所有范围内的通用（大而广），只追求在一定范围内的绝对好用（小而精）。
以前发的帖子也说到了一些我的通用的东东，最基础的就是“我的数据访问层”，它针对项目来说是通用的，针对数据库来说呢，就是一种数据库对应一个数据访问层（DLL文件）。
使用这个数据访问层再写一个新的项目的时候就不需要再写一遍Connection command DataAdapter 之类的代码了，省了很多的事情，我所需要关心的是：传什么样的SQL语句进去，返回什么样的结果（记录集）。
下一个通用的东东就是分页控件，他所负责的事情并不只是绘制页面（上一页、下一页等），而是包含了“业务逻辑”，我觉得对于分页控件来说如何分页（分页的算法）就是它的业务逻辑，既然叫做分页控件就应该实现如何分页（提取数据）的功能。否则威力会大大减弱。
分页控件使用的时候只需要为几个属性赋值，其他的事情就完全由控件包办了，目的很简单就是为了节省代码，还有就是重用。
分页控件完全使用SQL语句的方式提取数据，优点有两个：
1、不用编写存储过程。
2、查询条件更灵活，更方便。
当然效率也是很高，几十万数据不在话下，一百多万也没有什么问题。
在下面的就是如何显示数据了。（分页控件只负责如何提取数据）
DataGrid固然方便，但是仍然要做很多的设置，没个十分二十分的时间也不太容易搞定。能不能让显示数据自动适应字段呢？答案是可以的，只有想不到没有做不到。
在下面的是一个辅助控件了 —— 查询控件。
再作后台管理的时候往往需要一个查询功能，而查询条件往往是不确定了，很常见的情况是，一开始的时候只需要一两个字段作为查询条件，但是后来一使用发现不太方便，应该再加上几个字段作为查询条件，或者是已开始使用的是精确查询，后台客户要求改为模糊查询（like "%% "）的方式。
对于客户说这没有什么的，只是增加了一个小小的功能嘛。但是对于程序员来说往往需要增加很多的代码，如果使用了三层的话就更麻烦了。
UI层要增加文本框或者下拉列表框；
逻辑层要提取用户输入的数据，有可能还要加上判断；
数据层要修改SQL语句或者修改存储过程。
几乎每一层都要改一小下。
有没有这样的查询控件，要增加查询条件，只需要修改一下属性就可以了。答案同上。
下面的就是表单控件了。
几乎没有个表都要有一个对应的添加、修改的程序，也就是说表越多，对应的代码也就越多。
当然你可以用代码生成器来完成这些大同小异的代码，但是代码生成器并不完美，缺点也很多。
代码生成器并没有从根本上减少代码，只是代替了人工劳动，“自动生成了”n行的代码而已。
还是那个查询的例子，如果类似的变动发生在添加数据的地方，即使使用了代码生成器，也是要在次生成一遍代码，同样要修改每一层的代码，然后重新编译。
其实表单本身就是表的一种映射，当然这个就比较复杂了，字段数量不一样，类型不一样，需要的控件（文本框等）不一样，验证方式也是不一样的。
但并不是说复杂就做不成表单控件了，还是那句话：只有想不到没有做不到！
说到这里应该是结束了吧，主要的功能都作成控件了，但是还没有完！
下面的通用就是页面！
显示数据（记录列表、查询、分页）和添加修改两个页面。
如何让页面也通用起来呢？
1、使用控件。
2、把属性放在配置文件里面。
就是这么简单！
这样表再多页面也不会增加，代码也不会增加；有了变动也不需要修改代码。只需要维护一个配置文件就
可以了。而这个配置文件也不是手动添加的，有一个程序来专门维护！
这样的事情并不是空想，应该有很多人已经实现了，比如eform，在它的网站里看了一下介绍和演示，应该就是类似的思路。
我这里并不是为eform做广告，而是想说：人家能实现的，我们为什么不能实现呢？！
这是我的想法、思路，同时也实现了其功能，我现在写的 后台管理 就是这种方式。
欢迎大家来批批。
http://blog.csdn.net/jyk/archive/2007/02/03/1501849.aspx
这里有一个图，能够更直观一点。
http://blog.csdn.net/jyk/archive/2007/01/07/1476519.aspx
[解决办法]
不错
[解决办法]
have a look
[解决办法]
呵呵...
[解决办法]
UP
[解决办法]
接分
[解决办法]
接分
[解决办法]
好久不见jyk~~
[解决办法]
@_@
[解决办法]
up
[解决办法]
看楼主的思路，感觉和mvc很像啊
我曾经也参考ROR的原理写了一个简单的ASP.NET MVC框架
:P
------解决方案--------------------
你的思想已经很接近了呀 ^_^
[解决办法]
有点疑惑:
使用这个数据访问层再写一个新的项目的时候就不需要再写一遍Connection command DataAdapter 之类的代码了，省了很多的事情，我所需要关心的是：传什么样的SQL语句进去，返回什么样的结果（记录集）。
谁有提供这个SQL语句呢?
你写的是个数据访问层啊,调用它里面方法的人应该是写业务逻辑的程序员吧?
难道让他们提供SQL语句作为参数去调你数据访问层的方法?
[解决办法]
学习,有没有源代码的???????????
[解决办法]
年末都忙死了哦
~！~
[解决办法]
tmd 13号还要去投标，14号就放假
[解决办法]
ding!
[解决办法]
up
[解决办法]
不错
顶!
[解决办法]
挺不错, 我支持你!
[解决办法]
支持
[解决办法]
散分需要理由吗?看楼主就知道了.
[解决办法]
学习一下哈
[解决办法]
支持
[解决办法]
学习~
[解决办法]
mark
[解决办法]
关于列表和查询都可以作成通用控件，其数据都可以来源于配置表；
所以这些只要把控件做好了，一般不需要什么代码滴，只要配置就可以了。
还有一个动态生成页面控件，也是通过配置来完成的；做的时候用事件委托之类东西，
做比较简单的页面就方便了，配置下就可以，各个页面各自特殊动作再通过委托来处理；
这个动态页面控件和流程引擎相结合可以做成用户可视化的可配置流程。
[解决办法]
还有数据层现在一般都还是用在业务层里写SQL的（把sql写在程序里速度是很快但不是很理想），也有用NHIBERATE，感觉不是很好用；
最近在看写IBATIS这个感觉还可以，处理数据时相对比较OO，而且配置很灵活；
一般项目足够用了。
业务层间的耦合处理用CASTLE也不错，没接触过spring.net，不知道哪个更理想些？
[解决办法]
JF
[解决办法]
look look~~~~~
[解决办法]
学习
[解决办法]
up
[解决办法]
mark
[解决办法]
春节快乐，接分支持！
[解决办法]
好东西
[解决办法]
好东西。。。
[解决办法]
UP
[解决办法]
mark一下慢慢看
