--------------------------------------------------------

不管你如何去设计，基本的增删改查在程序实现里基本上是占有70%以上的工作量，有这么一个通用的处理基本动作的东东，想法是非常好的，毕竟，设计的东西再好也很难完全符合用户的需求，以后还是要改的，所以，真正做项目要求进度和质量的话，有这样的工具还是非常必需的

--------------------------------------------------------

要是这样做出来的东西就很难满足用户的要求了，这样做出来的产品说白了就是一个数据维护工具，如果客户的要求仅仅是维护一下数据的话，用sharepoint搭一个系统就足够了，都没必要做开发。

lz还没体会到一点，一个项目里面最麻烦的地方不是如何去处理这些基本的增删改查问题，而是在把用户杂乱无章的业务需求进行梳理并用程序进行实现。

用in的话性能虽然不好，但是开发效率还是不错的。

--引用--------------------------------------------------
　　记得我曾经和一个同事聊过，我问他为什么它的成员天天都要加班，他说他以他自己的工作量来安排新人，这样新人肯定做不完，那么就要通过这种方式来强化新人学习。我听完之后骂他说：“你神经，你的工资多少，他们的工资多少，能一样吗？再说学习有很多种方法，不一定要加班，人家下班之后还有其他事情，和女友约会逛逛大街，工作不是他们的全部。”
--------------------------------------------------------

这个超赞一个。

要是运行时动态的增加或者删除一个功能，rolevalue就全乱套了。

回帖中可以看出国内开发人的素质有多高。

推荐lz试试resharper

竞赛题考asp。net，有这样竞赛吗？

@猫咬狗
同感，我觉得membership就是一个标准的鸡肋，食之无味，弃之可惜。

表格控件的话还是简单点，关心显示就行了，什么时候能做到extjs grid那样的效果也就是表格控件的顶峰了，至于数据的查询，那是数据层的事，UI层插手这些东西没意思。

@姜敏
有很多从业人员对开发也只有这么多兴趣，有多少人愿意一直踏踏实实的写程序呢？有多少人都无时无刻不在想着将来转行做管理呢？如何一个人真的愿意一直踏踏实实写程序，那他成为一个高手也并非难事。

兴趣才是一个优秀程序员必备的要素，没有兴趣，什么都别说。

标题改成使用接口编程合适点。

@留恋星空

数据库存储数据说白了也就是IO操作，和xml保存数据方式也没太多的差异，但是一点，你的代码能比人家做数据库软件的人的代码写的好？不可能。说实在话，一般情况下xml也就是保存点基础配置信息，用来保存业务数据实在是得不偿失。

1，3，4，6赞成
2，5，7觉得不妥。
2.尽量缩小研究范围
既然选定只做.net，那么在这个领域里，你就不能画个圈子把自己限制死了，你不能说你只作asp.net,那么winform，windows服务，命令行程序，你就不关心了，必须在有所侧重的情况下，尽可能多了解一些知识，不要求很深入的了解，但是要摸对深入研究的门路，将来要做这方面的开发可以很快速的切入。
5.敢于接受新项目挑战，敢于尝试
敢于接受挑战是好事，但是敢于尝试我是不推荐的，绝对不要拿公司的项目做小白鼠做实验，公司项目是用来给你发工资的，不是你的试验田，那你的例子说事。
-------------引用--------------------------------------------
不过那个项目我是主程序员，因此在开发上有很大自主性。于是1.0时我尝试将所有用户文章保存在web服务器的xml文件里，而不是像传统项目那样保存在数据库里，以希望减少web服务器和db服务器之间的数据传输。结果1.0系统实际运行时确实达到了我的目的，虽然随着数据量的大量增加，最终导致了IO瓶颈。但通过后来对IO瓶颈的优化解决，我在文件系统、服务器进程、xml应用、代码规范和性能优化等方面学到了很多东西，倘若当初按原来的模式写程序，将错过学习这些知识的很好机会。
-------------------------------------------------------------
你拿公司的项目做实验啊，把用户文章保存到xml文件仅仅是为了让你学习文件系统、服务器进程、xml应用、代码规范和性能优化？你这个做法很危险，小项目无所谓，大项目这样做是要出生产事故的。技术上这也是个很危险的选择，放在xml文件里好做备份吗，可以做到增量备份吗，将来数据量大了如何保证读取xml文件的稳定性，xml文件将来可以做集群吗。这都是你处理不了的，有的东西该放数据库就放数据库，速度慢了你要去找原因，而不是用这种超常规方法解决。
7.跟上技术更新的脚步
适当跟进即可，旧知识都没有消化好，就急急忙忙学新东西，东西掌握的都不深入，你永远是个新手，新知识只要保持一定的关注即可，没必要马上学会。

比起当当，china-pub更让我恼火，高校用户可以免运费，但是像我这样的总消费了8k左右五星级用户运费照收不误。这些都是都是最早起家的电子商务网站了，服务方面一点改进也没有。实在是令人很失望。
lz对当当怨念很深啊，一早就发两篇随笔。

@netcorner

你要做的东西是一个很理想的框架，能做出来确实好，那是真的能做的那么理想化吗，不用写code就可以出系统，想起来确实很完美，我不知道你做的这套东西有多完美，比sharepoint强吗？即使是用sharepoint实施也是问题多多的，真的做到了能解决所有的业务问题吗，我觉得与其去研究这些东西，倒不如老老实实写代码。

@mclkyo
就是是一个实体一个BaseEntity
实体里面写自己实现的代码，BaseEntity放置生成的代码，实体类继承BaseEntity，（我说的BaseEntity是有多个的，一个表就会对应一个BaseEntity如：BaseNewsEntity,BaseUserEntity）。这样设计好处的就是数据库字段改了，重新生成代码覆盖一下就好了，不会冲掉你现在写的代码的。

@tornado123
代码生成和orm没有什么冲突的，orm一样的也是需要代码生成的。

@netcorner
我不是说了吗，用继承或者局部类来解决代码覆盖的问题。
对于我的框架例来说实体有两个:
一个BaseEntity抽象类，一个具体Entity类。
BaseEntity里面存放的就是所有的生成的代码。
Entity类的里面什么代码都没有直接继承BaseEntity。orm直接映射到Entity类。所有我们自己要实现的东西都写在Entity类里，BaseEntity里面什么也不用写，到时候数据结构改了，重新生成代码覆盖BaseEntity类即可，不会覆盖我们自己写得代码。
数据访问层和业务层同上。
重新布署生成也不是什么麻烦事啊，就是拷一个dll到服务器上，不比你在服务上改改配置工作量多多少。

Nhibernate不能脱离实体类，Nhibernate只是说内部实现用Hashtable或IDictionary的字典容器缓存了xml文件里面的内容而已。

@netcorner

我有两个框架一个是基于ado.net的一个基于orm的，即使是使用orm的话一样要也写一个数据层访问类来访问数据，和直接生成增删改查sql构建一个数据层访问类来访问数据库是差不多了，用orm并不代表除了实体类和配置以外数据访问类这块就不要生成代码了，唯一的不同就是使用了orm以后，生成的代码简洁点。



你提到Hashtable或IDictionary的字典容器其实Nhibernate内部也是有的，Nhibernate第一次运行时，会解析xml文件，在内存中生成这些东西缓存起来，供数据持久化使用，Nhibernate不会去时时解析xml文件的。

@netcorner
一点也不繁琐，生成的代码远比反射来的效率高，不知道你为什么对生成的代码的有意见，我们写得aspx页面不也会生成大量后置design.cs代码吗，但是这个也没影响我们使用啊，代码结构合理的话，这个不是问题，其实做到一点就好了，把生成的代码和自己实际使用的代码用继承方式或者是局部类的方式分开。这样重新生成代码对我们来说就没有什么影响了。

业务层没有管理事务啊，这个设定最终会把你的业务架空，导致你所有的业务层要处理的东西都转到DAL里面了，你的业务类最终会变成一个空架子，所做的事情仅仅就是调用DAL。

@狼Robot

你这个做法和orm去实现的东西是一样，没啥区别。

--引用--------------------------------------------------

但是你深入项目的时候去想想，我们的业务真能一切都可以定下来吗？人的思想总是在变的，客户的需求就更难以着磨了！哪天我们要给程序加个字段，你想想你必须要走几步改动？首先我们必须重新生成xml和实体，然后我们必须还得在业务逻辑中增加代码，还得在视图层加一个界面(如加一个input输入框等)！讲实话，加一个字段对这种orm框架的改动还是最少的，哪天假如说我们修改了哪个字段的名称、修改了字段类型，你想想，天呐！很难想像，和这个字段关联的程序都得改动!如果名称改了，ok，你可以全部替换它的原先名称，改成你新的名称。那类型改了呢？没办法只能手工一个个改掉所有的赋值的类型吧？视图层、控制层中的验证（js验证,业务验证）、逻辑层、实体层，xml配置等等都必须动。

--------------------------------------------------------



这和orm有关系吗，你不用orm这个问题就解决了吗？
顺便说一下是hql，不是hsq，个人觉得这个东西是Nhibernate里面一个比较失败的设定，事实上用Nhibernate开发要体现Nhibernate的效率的话，应该是要推荐使用Criteria查询的，hql的存在使得大量熟悉sql的开发人员去别扭的使用Nhibernate开发，反倒使开发更麻烦了。


--引用--------------------------------------------------
真不知道为啥像hibernate这样的框架还有一个xml配置文件？如果我真ORM的话，我不能把这些数据关系缓存起来，动态取关系不就行了吗？这样我不更灵活了吗？

--------------------------------------------------------
总得有个东西保存数据库的中表和程序中的业务类的对应关系，就象你说的缓存起来，那不也要存一个地方吗？没有这样的东西程序怎么分析啊。

其实树状结构还是用treeview展现更方便点，用Grid总是有点别扭。

@金色海洋（jyk）

我的测试环境是本本硬盘5400转，肯定快不了的说。

@Gray Zhang
你强，囧，快了还不敢用。
对了你是用纯sql测出来的是27秒，用存储过程测出来的是2分钟吗？

貌似没有对比的东西，我补充点吧，我用Nhibernate插入10w条数据的速度是70s，在一台配置类似楼主笔记本的机子上测试的。

@中华小鹰
请问这里的程序员从事的工作都是写一个windows操作系统或者开一个像sqlserver数据库或者是开发一个vs2005吗？实际点，大家都是做业务系统，别动不动就扯这些东西。

@Jeffrey Zhao
难度是降低了，我承认.net开发是简单了不少，但是也诞生了不少很烂的程序，但是很多通过拖拉控件做出来的东西和玩具有什么分别，不懂html，js的人也可以做程序，但是作出的东西质量又是如何。

在程序里生成sql不就完了，写存储过程多此一举。

@坏人

但是这个机械化耕作做得不好，很多问题解决不了，那就是问题，编程开发还没有简单到像做玩具一样，拖拉几个控件就可以了事的。

MS想降低开发的难度出发点是好的，但是他现在还做不到那个程度。

（一） 预定一种食物
1、客户甲定了一份牛肉萝卜包子，服务员记录后选择采购员。
要先选择有卖包子陷的资格的人，然后找能够卖牛肉和萝卜的人，如果找不到既能买萝卜又能买牛人的人，那么就得找两个人。然后还要看“承重”能力，比如要买50斤萝卜，某人只有40斤的采购能力，那么也是不能选的。还有负责的地区，还要考虑时间上不能冲突。

我觉得这个真的是设计过度了，管的太细了，按照你的说法的话，采购员必须要设置他可以买的原材料的资格，还要设置承重能力，但是一点加入这些功能的话会系统变得很难维护，因为这些数据变动的很厉害的，举个例子“承重”能力，某人只能买40斤东西，ok他买了一辆自行车，承重能力提高了，那你是不是要到系统里改一下用户的承重能力啊，不改的话，这个用户还不能去做采购大于40斤东西，用户业务跑不了，要是用户一只手摔伤了只能拿一般东西呢，实际使用过程用户对这块的数据设置会很烦的，业务有很多东西是随意的，不要试图去管理，一方面自己工作量变大，二方面客户工作量也变大了。

（二）
1、客户甲定了一份牛肉萝卜包子和一份三鲜馅饺子，服务员记录后选择采购员。

这回要找既有买包子陷资格的人，同时还有买饺子馅资格的人，找不到的话，只能派两个人去；然后是具体的食物，牛肉、萝卜、鸡蛋、虾仁等。同上。

这个我感觉超出你做的快餐系统的职责了，这块东西拉出来单做一个采购系统，对于你的快餐系统只需要关心一下原材料的库存即可，库存不足直接报警，采购部门看到以后自行处理。

做系统也包含一个帮助客户分析和梳理业务的过程，你不能跟着客户走，他说什么你做什么，你要站在系统的角度去审视人家的业务，给客户提出一些合理的业务调整意见，让这个系统运转更有效率，这样才能做出一个双方都很满意的项目。

用面向过程做出来的项目乱，用OO做也不见得好到哪里去，用不用OO关键在于你对OO的理解程度，我们项目用OO也差不多3年了，也不敢说对OO理解有多深，很多东西还是要参入一些面向过程的东西，OO是把双刃剑，用得好，项目会写的很优雅，用的不好，项目比面向过程的还难维护。

顺便问一句，lz的项目完全实现了你下面说的业务了吗？实现的话，你们可以直接卖产品，还是比较复杂的。我觉得做项目的话没有必要实现客户所有的业务，把握住核心业务就行了，什么是核心业务，就是客户用来赚钱而且这块人工成本比较高的业务，不管你的系统做得多好，你总有处理不了的业务，你就得好好规划那些系统管，那些系统不管，而不是一股脑都做出来。

看来出本书也不是件容易事啊。

@后台运行中……
是用不着你操心吧，我啥时操心这事了。要打印就打印吧，人家又不是没有公开精华版的内容，需要你操心人家出不出版干什么。

@后台运行中……
免费的，人家不都把文章列出来了，你自己看不就完了。
出版是为了给不想看的电子版的人准备的，别动不动就想着别人要赚钱。

和博主相比，你更像小毛孩。

@lswweb

path是冗余的字段，每当分类结构改变时都要更新path字段，用起来也是比较麻烦。

方法一,就可以了，查询需要递归并不影响性能，把所有记录读到内存里进行进行操作处理，远比方法二方法三快。

一般来说一般的系统类别一般也就是几十个或者几百个，都读到内存处理里很快的，对数据库也就是查一次就可以了，后面的方案完成一个操作要频繁的读取数据库，反倒性能不如方案一，当然系统很复杂类别比较多，达到上K级别的话，后面的方案可能会好些。

有功夫预测这个，不如预测一下以后的股市楼市来的实在。

@Q.Lee.lulu
非常感谢你让我找到了一个宝库，MvcContrib不但提供了几个视图引擎，还提供spring。net和castle的整合，很不错。

放在Application里面并不是最好的做法，我记得以前有个方法可以遍历服务器上所有的session，这样获取的在线用户才是最准确的。

不错，找就看<%%>不顺眼了，立马换了。

@tocnblogs
什么叫不正常，程序员就该天天闷着脑袋写代码啊，多点点缀的内容也不错啊。

骂微软的东西顶一下，微软这几年做了不少sb的事情把开发人员坑的可是够呛的。

好端端的FormsAuthentication实在是说不上，问题还是不少的，先不说多人同时登陆时有错把权限付给其他登陆用户的bug，本身也是存在漏洞，还不见得比session好使。

N天后，该死的商务部又打电话过来说，系统还得加个模块，需要从客户的老系统中抓些数据过来！

这个东西和接口是没有关系的，完全就是新的模块嘛，接口的意思可不是这样哦，o(∩_∩)o...。

推荐使用SessionFactory的GetCurrentSession()来获取session，这样来说可以更方便的管理Session的生命周期，可以通过设置hibernate.current_session_context_class来定义如何管理Session的生命周期。

看的书已经不少了，为什么感觉没多大进步呢？

你先好好想想，你这些书都看懂了，看进去了吗，少点浮躁，多点努力，什么都不是问题。

--引用--------------------------------------------------
最后人家是靠你的代码给的KW的Money么？
--------------------------------------------------------
不是，有这本事我还有功夫在这里闲扯啊，但是在项目组还不至于到写helloworld的地步。

@摆正自己的位置比较好
你觉得要是我参加一个项目只写过helloworld，那你就这么想吧，无所谓。
顺便给你讲个小故事：
苏东坡和佛印和尚是很好的朋友，但是两人也喜欢彼此嘲弄一番。有一天，两人坐着打襌。一会儿功夫，苏东坡睁开眼问佛印：「你看我坐襌的样子像甚么？」佛印看了看，频频点头称赞：「嗯！你像一尊高贵的佛。」苏东坡暗自窃喜。佛印也反问道：「那你看我像甚么呢？」苏东坡故意气佛印：「我看你简直像一堆牛粪。」佛印居然微微一笑，没有提出反驳。回到家中，苏东坡得意的告诉他的妹妹：「今天佛印被我好好的修理了一番。」当苏小妹听了事情原委后，反而笑了出来。苏东坡好奇的问道：「有甚么好笑的？」「人家佛印和尚心中有佛，所以看你如佛；而你心中有粪，所以看人如粪，其实输的是你呀！」苏东坡这才恍然大悟。