好东西学习

呵呵，本来是想写写如何向百度申诉的流程，免得有同样需求的朋友没头绪。

不过看来大家好像是更同情恶意造谣的人。三人成虎，众口铄金。如果真是有问题，反倒不用删了，毕竟是实际情况。就因为没问题却被诽谤，所以才不能容忍。
大家可以访问一下我们公司的留言板（http://portal.jkl315.com/LeaveWord/Default.aspx），看看是不是在“防民之口，甚于防川”。

防民之口甚于防川啊
只要公司没啥问题还怕别人说吗？

那有什么办法啊，让删就删呗。
现在专门安排了一个人每天干这个，工作都耽误了，郁闷死我了。

哼哼,删得了一处,删得了所有么?!!!!~~~~~~~~~```````````

@金色海洋（jyk）
简单是简单,但那个系统不是从简单才演化到复杂的.有时候那些SOA过于庞大了,,不是所有的人都是开发大型系统的,现在中小型的系统还是主流,SOA中的很功能就显得很多余了.关键还是合适就好,就看你在效率和可开发性,可维护性中找平衡点了.
我想应该更多的是吸收其中分层的思想,如果你能亲手搭建一个简单的三层的系统出来,相信会更深的体会到分层的意义.

写的确实不错，我都忘记什么叫三层了，是你给我了回忆，谢谢！受教！~

补充一句，“可惜咱都不是”，我怕埃板砖……

偶遇，照你的说法去做三层，顺手关了页面，做到半道又回来找，只记得笨笨的熊窝，幸亏只记得，博客园里，瞟见楼主的不吐不快，顺道看了看，很真实，很难得。值得一赞，只有真实的人才知道。不问辩得标不标准，至少我很钦佩。英雄惜英雄的感觉。

也看文章，也看评论，也看自己的想法。

其实我认为写程序用什么方法无所谓的，关键就是你程序的最后实现效果和效率

个人意见，请问各位现在用三层的牛人有多少，有多少人能写的把类都封装的完美的

认真的看完了，学习了不少，不知道有代码没？慢慢学习。 如果有的话请发到我的邮箱里，谢谢啊！

认真详细的看了一遍发现理解了点了,还是得在项目的具体开发中来看.

存在数据库中的图片，也可以通过网址的方法来显示，如“http://www.web.com/showImage?id=n”，还是直接调用网址即可。
你可以看一下相关资料。

图象的数据源如果存放在数据库中 请问应该怎么添加

挺好的，希望尽快给代码啊。

我用了怎么显示不出来呀！！

支持原创，反对那些只会起哄，不做实事的人！

@水言木
对于数据图添加新字段基本上没有很好的办法，因为这种改动对程序来说属于完全陌生的行为，不过可以在数据库中添加参数表解决。

@金色海洋（jyk）
差太多了,我的实体可以for循环它的属性,嘿嘿,不依赖属性名

因该以数据字典为中心的。改动数据字典自然就会映射到界面。这样改动就很少了。界面元素根据XML配置文件动态生成，增删改也由配置文件控制，这样的话，某些需求改了，只要改改配置文件就OK了。

@haceknliu

可能是我的表述不清楚，这里只是想说明IDA，DAL的关系而已，而不是说不要接口编程，举例的代码就是面向接口而不是面向实现的。
我并不是说实际编程中IDAL没用，而是在理论上分析时，抛开IDAL可以让人看得更清晰而已。

不错

@ 私家侦探
那你的方法和我的表单控件的思路不就是差不多了吗？

凑个热闹。分层的目的正如LZ所说，是为了OCP，需求的变化不至于让我们到处修改我们的程序。用不用3层，就看你是否有更好的办法保证OCP就行了。先考虑维护而不是考虑效率就是正确的方式

看了文章，也看了评论！~
赞美的也有，鄙视这种三层的也有
感觉，既然都是“手段”，而不是“目的”，那么谁的生命力强，谁就好。这个生命力包括性能、开发速度、维护、易用性等n多方面

@xiao_p(匿名)
确实啊,要用先进的主流的东西,毕竟是在公司里面混的
petshop是打理论基础的,

@金色海洋（jyk）
看过有些人用反射,我不是,我的替代方法在后面有说了啊,反射也不一定就是要一概反对,比如那种增删改操作,就可以用反射把界面的控件和model的各属性绑定在一起,不然如果有三十个属性那不是死了吗,这种情况的反射几乎是没有影响的,有时候写代码也不一定要太钻牛角尖,要灵活

我的model类不单单有对应表字段的属性还有表字段名常量还有一个索引,用索引获取属性名或设置,也可以获取model中各个表字段名,用工具生成的

不过这种做法我即将要淘汰掉掉了,因为不是主流做法,只有跟着主流走才不会吃亏

如果可以，打死我也不选择这种三层架构，虽然也是从这样的三层架构走过来的。

现在有那么多的好的方式可以去尝试，orm，linq，为什么还要选择三层这种最最古老的方式！

ps:我说的三层是楼主的三层，就是那些dao，daofactory之类的！

楼主对三层的理解让我受益匪浅，特别是最后关于替换任何一层而不需要修改其它层才是完美三层的分析。

@水言木
如果是添加、修改数据，可以参考我的那个表单控件。
对于增加字段绝对是一件很容易的事情。只下修改一个地方就可以了。
http://www.cnblogs.com/jyk/category/135295.html

如果是显示数据的话，其实直接使用DataTable 是很方便的。

@私家侦探
这个，反射是不是有一个效率的问题呢？如果是高访问量的网站的话，性能损失是不是太大了呢？

但实际是即使你如此编码：“IUserDAL iUserDal = ClassFacotry.CreateUserDAL()；”，那么在执行“iUserDal.SelectUsers()”时，其实还是执行的UserDAL实例，而不是IUserDAL实例，所以IDAL在三层中的位置是与DAL平级的关系。
你的这段话,我不认同,虽然我不对三层结构还不太清楚,但从面向对象角度上来说,应该针对抽象编程,而不是细节.代码的可复用性,才较好

--引用--------------------------------------------------
水言木: 我比较疑惑的是,当数据库表增加一个字段时,DAL要改,Model也要改,UI要改,只有BLL“可能”不要改，不知有何良策？（当然，虽然要改，但是比不分层时好改多了）
--------------------------------------------------------

那是封装得不好,依赖太强了

比如在dal层用反射来获取model对象属性(当然还有其它办法),这样你要改字段增加字段的话只改model类就好了,其它地方有用到model的因为并不依赖model的具体属性名,自然能动态处理了,好好想想吧,我的实际办法是让model有索引,还有一个"数据库字段名"的字段,并且可以从索引获取字段名或者属性值

--引用--------------------------------------------------
GuoYong.Che: 个人观点：
Petshop可以学习它的思想，但照搬的意义不大，对于.NET 2.0来说，个人觉得还是使用类型化DataSet方便，一个DataRow实质就是一个Model，一个DataTable就是一个IList<T>。扩展性、灵活性虽差点，但开发效率不知强到哪去了。
--------------------------------------------------------
这个还是很方便的,其实都是以实现为目标的,但是要综合的太多的了.

感谢楼主的文章

受教了！！

我比较疑惑的是,当数据库表增加一个字段时,DAL要改,Model也要改,UI要改,只有BLL“可能”不要改，不知有何良策？（当然，虽然要改，但是比不分层时好改多了）

写得很好，对于那些对三层比较迷糊的人来说，能够让他们对三层的理解更清晰一些。

但是这种简单的三层方式（或者说是简单的应用），好像优势越来越不明显了。

比三层好的方式还有很多。

Model改成Entity更合适吧

很喜欢linq的东西，用他搞分层应该简单很多了吧

--引用--------------------------------------------------
GuoYong.Che: 个人观点：
Petshop可以学习它的思想，但照搬的意义不大，对于.NET 2.0来说，个人觉得还是使用类型化DataSet方便，一个DataRow实质就是一个Model，一个DataTable就是一个IList<T>。扩展性、灵活性虽差点，但开发效率不知强到哪去了。
-----------------------------------------------------
实际上是方便多了，但是三层也照样可以方便，利用代码生成器就OK了，比生成每个DATASET更方便

楼上说的有道理。在2.0中我也是这样用的，以为很少人用这个方法，感到很困惑。今天找到知音了。
希望大家对此提出自己的看法。

--引用--------------------------------------------------
GuoYong.Che: 个人观点：
Petshop可以学习它的思想，但照搬的意义不大，对于.NET 2.0来说，个人觉得还是使用类型化DataSet方便，一个DataRow实质就是一个Model，一个DataTable就是一个IList<T>。扩展性、灵活性虽差点，但开发效率不知强到哪去了。
-----------------------------------------------------
嗯，有道理！

学习...

@靳增锋
呵呵，同道啊！
确实是这样，充满了功利心，怎么能静下来搞研究呢。

个人观点：
Petshop可以学习它的思想，但照搬的意义不大，对于.NET 2.0来说，个人觉得还是使用类型化DataSet方便，一个DataRow实质就是一个Model，一个DataTable就是一个IList<T>。扩展性、灵活性虽差点，但开发效率不知强到哪去了。

@大柳树
这几天如果有时间，会继续写一下RBAC的文章，到时会有代码的。
这样配合着实际项目的代码，看起来应该更有效果。

支持

现在是个急功近利浮躁的时代，大的环境如此，唯有身居闹市心远地自偏了。关键还是个人修养和追求。看来程序员也该修身养性了。

写的很好，老板放个代码吧

真是温故而知新啊,又多学到一点,呵呵~~~