请教一下关于web开发经验

[_lee_chong]

我用
html+jq ajax+ashx的方式
这样 和用 aspx比起来有什么优缺点吗?

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

[觉悟之时]

调用存储过程的那一层实际上是属于数据访问层。

[_lee_chong]

[Quote=引用 1 楼 的回复:]

调用存储过程的那一层实际上是属于数据访问层。
[/Quote]
我知道阿，可是那一层只是调用存储过程了，如果还写那么多类的话感觉很没意义，所以我想不按照之前学的一张表就一个类。。。。

[anzhiqiang_touzi]

我看过很多人写的三层开发
都是数据访问+业务逻辑+UI
但是很多来讲业务逻辑都是过场而已。这是因为他的框架就这样了。
严格的业务逻辑层次来讲：业务逻辑要体现业务逻辑的特点。要不然没太多的意义的

[_lee_chong]

[Quote=引用 10 楼 的回复:]

单就你的问题来看，你只要是将ashx面向业务、基于业务知识来设计，而不是根据什么数据库增删改查操作来设计，这就是一种很好的BLL设计思路。我经常举一个简单好理解，移动公司只要给sp提供4、5个接口的api，于是就催生出每年几十亿的市场来了。那么你设计好ashx，知道哪些客户端可能需要（例如一个c++写的android程序也是需要它的），如何控制合适开发哪些权限，如何控制业务逻辑（例如腾讯的业务逻……
[/Quote]
大哥多谢了,虽然很多东西不是很清晰;
但是大哥的意思应该是更多的关注bll与ashx;
而所谓的dal层只是用于将数据库抽象数据转换成那个什么我们需要的数据,
只要实现就好;不用刻意的去管那些方法,甚至不用去专门一一做那些个对应与表的实体类;

专注于业务么...
那个我看过一点点的mvc架构的介绍,总感觉mvc那种围绕功能和视图(厄,这样理解不知道对不对)好像比传统3层的分层更适合于这个开发;
我不知道我这样理解对吗,如果可能的话我需不需要去尝试一下学习并且使用mvc架构来做呢?
多谢各位了!!

[_lee_chong]

[Quote=引用 3 楼 的回复:]

我看过很多人写的三层开发
都是数据访问+业务逻辑+UI
但是很多来讲业务逻辑都是过场而已。这是因为他的框架就这样了。
严格的业务逻辑层次来讲：业务逻辑要体现业务逻辑的特点。要不然没太多的意义的
[/Quote]
我就是这个意思啊,如果只是为了所谓的3层架构,就尽是些1句话的函数,总感觉不是那么回事....

[wylp_19]

将业务逻辑和数据访问放到一起 方便以后扩展吗 方便重用吗

[yyl8781697]

[Quote=引用 3 楼 的回复:]
我看过很多人写的三层开发
都是数据访问+业务逻辑+UI
但是很多来讲业务逻辑都是过场而已。这是因为他的框架就这样了。
严格的业务逻辑层次来讲：业务逻辑要体现业务逻辑的特点。要不然没太多的意义的
[/Quote]
++++这种现在很常见了，为了三层而三层，如果直接写个二层感觉又别扭。。。呵呵

[以专业开发人员为伍]

[Quote=引用楼主 的回复:]
我用
html+jq ajax+ashx的方式
这样 和用 aspx比起来有什么优缺点吗?

我的数据库操作做成存储过程,这样的话我直接业务逻辑层就可以调用存储过程了,数据访问层基本没用了,我想把它取消掉......
可是有很些人都是用的存储过程,同样别人也用3层...那么这两种方式肯定都是好的,那我是哪里理解错了吗
[/Quote]

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

[以专业开发人员为伍]

在早先，我讨论过自定义ORM，来处理随时切换不同数据库（实际上主要是把关系数据库与面向对象数据库相切换，而不是仅仅适合关系数据库之间的切换）、支持Linq方式的查询，这类DAL抽象层的问题。

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

[以专业开发人员为伍]

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

所以你把精力放那个到关心ashx上而不纠结与后台的实现，就是进行业务逻辑设计、面向服务产品而开发的很好的思路。

[IT-Style]

典型的为了三层而三层...
支持sp1234