今天看到个关于 Hash 封装，实在理解不了

Question

譬如对于一个产品展示网站(不涉及购物流程)，按照目前流行的分层结构，可能首先有一个 Model，然后是 Dal，，如果不是很变态的人，大概不会有 Bll，最后是 UI。OK，就以此为例。对于这一类型的网站，客户最常变更的是什么呢？恐怕是数据库表结构吧，因为客户今天会要求加一个产品颜色，后天又要求加一个分类，大后天再加一个保质期，你在做之前，能准确的预测到这些具体的需求变化吗？如果能，那你改行算命好了，一定财源滚滚，何必做程序员这份又辛苦又没前途的职业呢。
既然算命的路走不通，那还是来改数据库表结构吧.表结构变了，那还得改 Model，然后是 Dal，最后是 UI，恭喜您，这么小的一个变化，竟然可以熟悉经典的三层结构，Very Cool!
可是很痛苦，如果你认为这样也能痛并快乐着，那你是 90 后，当我没说。其实，这种类型的变化，如果不是初入行的，大约都能猜到，既然能够猜到，我们为什么还要做出这么痛苦的选择呢？针对变化进行封装，这是一个很重要的原则。既然 Model 这一层经常变动，那就从这里着手，很简单，抛弃一个表对应一个对象的做法，何必背负那么沉重的包袱？用一个 Hash 来封装你所谓的实体类，根据表结构动态生成名值对，然后填充页面，是不是简单很多？并且在表结构修改后，你的代码只需很小的改动，甚至都不用改，直接在页面上添加与表字段相对应的控件就可以了。这样，只要一个通用的数据库访问的层，其它所有的代码，直接在 UI 里写好了。
最近公司接的小项目上也确实有这种情况，就是多次更改数据库结构，我也确实是按照它上面的做的，改了MODEL改DAL，然后改BLL。
看到说可以用Hash封装，但是百度了很多也没有找到一个标准的用法。
是不是可以理解成，可以根据SQL或者ACCESS的表结构动态生成model类？但是具体怎么用呢

Answer 1

Hash封装还不如直接用DataTable呢！

Answer 2

关于什么”HASH封装“，懒得管这种东西。你写一个Class，那么你给他增加或者减少一个属性的速度更快、而且代码更优雅。别以为“散了于是就高效率了”，那还是因为你层次就在散的那个角度。就算我们早就扔掉了关系数据而使用NoSQL，我们也不敢说越散越好这种简单的话。

Answer 3

其实争论是意义不大的。为什么？因为有些人过度纠缠什么“三层、模式”之类的。这些东西当然很必要，但是更重要地是，需要脱离了程序员编写程序（程序员设计的界面往往很恶心，用户操作体验简直是病态）的那种技术。例如我们在屏幕上画一条优美的波浪线，然后既可以让一组照片按照这个路径在那里动画地出现和翻滚展示了，如果你做了几十个这种设计几乎都不需要编程，那么你才知道什么叫做UI开发。而在这种工具不合适的时候，我们可以花半天功夫开发一两个行为插件，增强其功能。那种整天就在研究“基本的”编程语句的人，怎么能有精力再去关注这类UI组件架构的开发呢？怎会去理解尽量不编码而今需要声明（不管是html/css还是xaml/style）方式的UI开发理念呢？所以只能把精力放在争吵一些基本理论上。

Answer 4

LZ需要ORM框架解决你所说的问题。

Answer 5

csdn的.net论坛是一个“基本的编程语句”为主的论坛，如果说100个帖子中有3个能是设计师的角度提出的问题，那么已经算是很不容易了。这时候，你会看到，不管如何纠结“理论”，做出来的也就是千篇一律的那种围绕一个数据库表做个“增删改查”的界面。围绕这种UI创意，讨论技术，其实是很浪费公司的人才的。

Answer 6

实体类使属性都是强类型的，并且方便跟踪，换成 Hash，不跟 DataTable 一样了吗

Answer 7

学学EntityFrameword
然后再学学CodeSmith

Answer 8

事实上C# 4.0的dynamic类型就是如你说的，内部是一个Name-Value Pair。