请教一下关于web开发经验

我用
html+jq ajax+ashx的方式
这样 和用 aspx比起来有什么优缺点吗?我的数据库操作做成存储过程,这样的话我直接业务逻辑层就可以调用存储过程了,数据访问层基本没用了,我想把它取消掉......
可是有很些人都是用的存储过程,同样别人也用3层...那么这两种方式肯定都是好的,那我是哪里理解错了吗

解决方案 »

  1.   


    所谓三层开发，本来就是指有BLL层，至于使用ADO.NET、Linq to EF或者什么莫名其妙的自定义一大堆DAL命名空间的类型，那都是DAL层。不是说使用ADO.NET就不叫做DAL层了。
      

  2.   

    在早先，我讨论过自定义ORM，来处理随时切换不同数据库（实际上主要是把关系数据库与面向对象数据库相切换，而不是仅仅适合关系数据库之间的切换）、支持Linq方式的查询，这类DAL抽象层的问题。但是实际上可以看到，很多人都是为了三层而三层，它强迫那些刚工作的学生一定要弄个什么DAL目录、里边为每一个数据库表建一个class，整一些莫名其妙的“增删改查”方法，而且其中的“查”所依赖的还是空洞的、没有说明任何内涵的string（也就是说根本没有像linq那样将查询语言单独抽象化）。这种DAL实在是非常悲催，打着“三层”的名义实际上实现出来的东西的层次很低，每一次修改数据库结构时都要修改一大堆底层代码。所以我觉得我们可以退一步，顶多使用SqlHelper也就行了，不要再高要求了。
      

  3.   

    单就你的问题来看，你只要是将ashx面向业务、基于业务知识来设计，而不是根据什么数据库增删改查操作来设计，这就是一种很好的BLL设计思路。我经常举一个简单好理解，移动公司只要给sp提供4、5个接口的api，于是就催生出每年几十亿的市场来了。那么你设计好ashx，知道哪些客户端可能需要（例如一个c++写的android程序也是需要它的），如何控制合适开发哪些权限，如何控制业务逻辑（例如腾讯的业务逻辑团队当然就要研究何时放出哪些特殊号码、这些号码有些什么关联属性），这就是业务逻辑，脱离了数据库编程的低级“技术”而针对业务和通讯行业来设计业务逻辑。所以你把精力放那个到关心ashx上而不纠结与后台的实现，就是进行业务逻辑设计、面向服务产品而开发的很好的思路。
      

  4.   

    大哥多谢了,虽然很多东西不是很清晰;
    但是大哥的意思应该是更多的关注bll与ashx;
    而所谓的dal层只是用于将数据库抽象数据转换成那个什么我们需要的数据,
    只要实现就好;不用刻意的去管那些方法,甚至不用去专门一一做那些个对应与表的实体类;专注于业务么...
    那个我看过一点点的mvc架构的介绍,总感觉mvc那种围绕功能和视图(厄,这样理解不知道对不对)好像比传统3层的分层更适合于这个开发;
    我不知道我这样理解对吗,如果可能的话我需不需要去尝试一下学习并且使用mvc架构来做呢?
    多谢各位了!!