这段时间，看到了很多分层和架构的内容．先谈谈我正在做的项目，可以说这个项目是模仿Petshop，只是客户确定用数据库SLQ Server 2000,不会变，所以没有用什么工厂模式． 可能这个也是目前用的比较多的结构了，做的过程中有个很深的体会，也是让我寻找更好框架的原因，我们的BLL层，根本就没有东西，原因我想应该是应用了SP的缘故，业务逻辑散落在各个角落里．说实话，我挺讨厌SP的（报表除外），我个人也认为，这根本不是真正的面向对象．当你的存储过程达到几百个的时候，当你有很多的连接查询的时候，真是举步为艰！下次如果再用这中架构，如果确定用存储过程，还不如不要BLL层．公司给我们培训架构，讲的仍然是三层，难到.NET里面没有别的了吗？无意中看见了LoveCherry的帖子：小调查，大家现有项目系统构架都是怎么样的？
http://community.csdn.net/Expert/topic/4937/4937348.xml?temp=.8395655好象真的都在用这种结构，不过LoveCherry在学习NPetshop,里面用到了Castel,用到了MVC模式，
碰巧我也学习了Java里面的Struts，经典的MVC,个人认为，MVC更加强调业务逻辑，Hibernate等一些框架其实都是帮我们解决除了业务以外的问题，让我们有更多的时间去研究实现业务逻辑,建立领域模型．Petshop 太简单了，所以我们忽略了他的业务，我甚至偏激的认为，Petshop的简单"毒害"了很多人，包括我．我想研究NPetshop,看看.Net里面的MVC是什么样子的．不断的思考和不断的总结才能有新的发现，请各位谈谈这方面的感受和一些心得．推荐除Petshop 以外的架构．
http://community.csdn.net/Expert/topic/4937/4937348.xml?temp=.8395655好象真的都在用这种结构，不过LoveCherry在学习NPetshop,里面用到了Castel,用到了MVC模式，
碰巧我也学习了Java里面的Struts，经典的MVC,个人认为，MVC更加强调业务逻辑，Hibernate等一些框架其实都是帮我们解决除了业务以外的问题，让我们有更多的时间去研究实现业务逻辑,建立领域模型．Petshop 太简单了，所以我们忽略了他的业务，我甚至偏激的认为，Petshop的简单"毒害"了很多人，包括我．我想研究NPetshop,看看.Net里面的MVC是什么样子的．不断的思考和不断的总结才能有新的发现，请各位谈谈这方面的感受和一些心得．推荐除Petshop 以外的架构．
Duwamish 也不錯哦!
http://community.csdn.net/Expert/topic/4878/4878075.xml?temp=.9017298
反思反思
IDataAccess 数据库打开关闭、执行SQL等
IDataAccessFactory 工厂，根据配置文件实例多种数据访问，已实现Access、SQLServer、Oracle、DB2、OleDB、ODBC2、EntityAccess，跨数据访问，调用数据访问层，为了与DataAccess实现松耦合，增加了IExeSql接口，因而只要你的数据访问实现了IExeSql接口也行，已封装 IEntityAccess，依赖IEntityFacade，调用IExeSql，是IEntityMap与DB的中间产物，已封装
IEntityMap，依赖IEntityFacade，调用IEntityAccess的增、删、改查
IEntityFacade，不用说了，仅仅是对象，这样不像强类型暴露了数据结构这里的命名刚更改为现在这个名，正好和数据访问、中间层、表现层对应3、实体定义与实体管理，实现IEntityFacade、IEntityMap接口或EntityAccess给定的基类
EntityDefine如PersonEntiy
例如成员Name，Age，这个名字不一定是数据库中Person表的字段名，这样很好的保护了结构不暴露，UI调用也方便，直接调用person.Name比强类型的dataRow["Name"].ToString()更直接方便，如果用强类型，UI还要了解结构，不爽。
如果你不会在意像DataSet强类型暴露数据结构，EntityManagement直接继承IEntityFacade的已实现的基本类EntityFacade并实现IEntityMap EntityManagement如PersonManagement
调用者自己用成员适配模式定义EntityManagement适配IEntityMap的增删改查，这样就不会暴露数据结构
如果你不会在意像DataSet强类型暴露数据结构，EntityManagement直接继承IEntityMap或它的基本实现EntityMap类
4、还有业务外观和业务逻辑，调用EntityManagement，至于逻辑如多个实体对象利用COM+达到事务共享 因为各个对象在不同的数据访问层中提交，但很多时候需要事务，这里启动MSDTS5、用户界面层，直接申明实体如PersonEntiy并用EntityManagement如PersonManagement达到数据存取目的。PersonEntiy仅仅是根据成员读写数据，调用PersonManagement的增删改
这样，UI不像调用强类型的DataSet还要清楚字段名等，而直接以对象方式存取，屏蔽了数据结构。需要说明的是：
只要实现EntityAccess的IEntityMap接口，数据存取不用你写一行SQL，自动跨数据访问。-----------------------
另：大家可以到网上看一看 孙亚民 的文章与他设计的架构，他的架构很不错。实体是继承于DataSet，实体定义是用XML描述的，并说明了Java EntityBean优缺点于是进行改进。但是我觉得最大的弱点就是UI调用实体读写数据的时候，先不说数据结构暴露，但总是要dataRow["字段名"]就感觉不爽。
之前我也用XML搞过，但是没有孙亚民那样定义的细
我用XML实际上定义的是Web/Win表单与数据存取之间的关系，也就是说只要你定义了这个XML
你不用写程序我就可以把Web/Win表单提交到数据库如有兴趣可以一起探讨，在17556475群共享中，有三层示例和我说的 Web/Win表单通用数据存取
nhibernate,spring等
还没有打算做Java，学习这个只是为了学习一个新的框架，走出去海阔天空．看到了NPetshop,.net里面的MVC，不知道是不是很值得一看了．看来是到了学习一些新东西的时候了，Castle首选，然后是IBatisNet．
http://www.microsoft.com/downloads/details.aspx?FamilyID=98c6cc9d-88e1-4490-8bd6-78092a0f084e&DisplayLang=en好多项目都是把业务逻辑直接写入SP，这样的优点是可以提高代码的执行效率，以及便于维护。为了更好的实现组件化，也就是面向对象化，你可以把业务分割成小单元，分别用SP来实现，然后封装成BLL。这样就可以平衡面向对象，代码执行效率以及控制工程成本三方面的需求。
莫非大家都不用代码生成工具么?
莫非大家都不用UML么?
-------------------------------------------------
我的BLOG：http://blog.csdn.net/beepbug/
2、我接触这方面是太久，不过也有些自己的想法，首先我觉得，我们空空的去讨论、评价某一类架构是片面的，甚至是有反面效应的，同时也会误导了其他人。说的大点吧，马克思列宁主义好吗？当然好，但是它能完全的适应我们现在的社会吗？所以我想这个好是有前提条件的，比如在什么历史背景下，在什么样的人文环境下等等...那么我们软件的架构也是一样的，我们不能说PETshop不好，（暂时抛开它是否有缺陷）但是它的好也许只是适应某一类的项目，除了学习其架构我们没有必要在我们的每一个项目开发的时候都去模仿它，最重要还要就我们具体开发的项目的实际情况而定，甚至我觉得把我们的项目分成简单的2层都是没有问题的，在某些情况下也许效果会更好...
其实这个理解也无可厚非，但是我觉得MVC更加强调的是模型．想想我们的结构*.aspx.cs文件和DAL 有很多文件，BLL 却很少，很大一步分原因是我们太依赖于存储过程． 即使我想把这些业务防入BLL，但是我还是不知道什么是"控制逻辑＂，什么是业务逻辑． 虽然我知道要建立领域模型，但是又有谁能真正做到呢？其实我发帖的目的一个是寻找除ENTITY/DAL/BLL/UI这种架构，扩展自己的视野，
二也是想提醒自己和别人，不要什么都加在*.aspx.cs，最好能建立领域模型．如果不能建立领域模型，决定加在*.aspx.cs的时候，加的内容到底是"控制逻辑"，还是"业务逻辑"．
但是不知道你有没有想过，MVC为何没有数据访问？为何要把Control加上？我想之所以加上Control，是为了解放Model，让我们有更多的精力去解决业务逻辑．
但是在三层结构里面，根本没有提到Control,当然如果你能在＊.aspx.cs实现控制逻辑，在BLL实现业务逻辑，也算是个伪MVC吧！
但是MVC里面的Model不依赖于任何一层，三层却不一样，这点也是说明了Model很重要吧！
---------------------------我觉得这两者之间区别很大，或者说根本就不一样．说一点：MVC里面的Model不依赖于任何一层，三层里面的BLL呢？Model不依赖于任何一层, 这点很重要．
我倒是觉得MVC就是Document/View加上Document的Control而来的。将M和C放到一层，将持久层独立的时候就形成了UBD（UI/BLL/DAL）。
事实上MVC和UBD并不冲突。
*.aspx.cs应该属于UI还是BLL?我现在的理解，*.aspx.cs应该属于UI.ASPX和MVC没有本质的区别吧！如果是我理解错了，请指正，否则别人看了这个帖子，容易产生误解．
正如你所说，本质上这两者是一样的，不同的是我认为MVC更加强调业务．
目前我的理解，三层还是没有突出业务的重要性，
微软做好了强大的ASPX,做好的强大的数据访问，可能是让我们有更多的时间去处理业务，但是目前来说，BLL的确很瘦弱，所以我才说＂请重视业务逻辑＂．
多的很，一个页面可以，两个页面也行，太多页面就不行了，看情况，非得搞个3层n层的那也得看场合，没有最好，只有最合适自己的。屎，有屎存在的道理
米，有米存在的道理
燕窝，有米存在的道理你让狗吃燕窝，可以么？
完全可以，也完全没有必要。
像这样嘛。
webform1.aspx.cs里
if(this.text1.text == "")
Response.write("gasfasdfsadfsdf")
if(this.text2.text == "")
Response.write("dfsadfsdf")
classa aa = new classa(this.text1.text,this.text2.text)
aa.getmoney();
然后在写一个类文件
在这里定义这个classa这个类嘛。？、、？、、、????????????????
都是这样做太蠢了吧
UI逻辑，还有什么逻辑，，哦，业务逻辑在哪，定义一个类文件最后说这个看场合，还是狠对的。。就像用sp，orm哪东东。租的服务器牛一样，你能用orm嘛。
只关心业务逻辑的架构我认为是好的架构!
存储过程越简单越好,比如一条select 语句,^_^
如果架构合理,本人推荐这样使用!存储过程用生成器生成两秒钟搞定.
稍微有点复杂的语句都不要使用存储过程了,且不说维护代价,看着我都觉得不爽.
除非涉及到几个表的复杂计算,才值得去考虑.