一个关于三层里的数据层的疑惑——SQL语句算不算业务逻辑？
三层，一般分为 UI层、业务逻辑层、数据层。
如果我不用存储过程，只使用SQL语句的话，那么SQL语句要放在哪一层呢？
如果你的回的是 数据层 的话，那么下面这个问题是怎么回事呢？
假设一个环境，一个产品展示的网站，需要在首页里显示最新的十个产品，需要显示产品的名称、编号和价格。那么我需要写一个SQL语句：
select top 10 名称,编号,价格 from 产品表
那么这条语句是不是要写在数据层呢？当然要放在数据层了，逻辑层怎么可以有SQL语句呢？
好的，现在看看业务逻辑变化的时候我们要做什么？
假设现在要增加一个信息，要显示产品的产地。这是是需求的变化，业务逻辑的变化，对于客户来说这个没有什么难的，三个信息都显示了，再加一个产地有什么难的呢？（这样的变化也是很常见的）。
那么我们看看程序要改什么地方。
首先想到的就是那个SQL语句，显然必须要改一下：（不改的话产地怎么出来呢？）
select top 10 名称,编号,价格,产地 from 产品表
这个是在数据层的，也就是说要修改数据层。
好了我们有新的数据了，我们要把它显示出来，UI层也是要改的吧。又改了UI层。
假设我们用一个实体类来装载记录集，那么我们要修改实体类（加一个属性。实体类不算作逻辑层吧），我们要修改填充实体类的代码，这段代码也是放在数据层的吧？
好了现在我们改了数据层、UI层、实体类，那么逻辑层呢？要不要修改呢？好像不用吧。
明明是业务逻辑的变化，我们为什么要改数据层、要改UI层（改UI蹭还算说得过去），可是却没有改逻辑层？
是我的理解有问题？是我的设计不对？到底是什么原因呢？
是我学习的不够深刻？
兄弟们你们有没有遇到过类似的问题呢？你们是怎么解决的呢？
SQL语句 到底算做什么？
什么您说不用SQL语句，改用存储过程。那我还是要改存储过程，还是不用改逻辑层。
欢迎大家讨论，人多的话我一定会加分的，回复数超过分数我就会加分，加到200分为止（只能加到这么高了，目前我还发不了300分的帖:)）。
ps;
我的观点：SQL语句 应该算作业务逻辑，应该放在数据层的外面。
或者说把数据层分为两块：数据访问、访问规则（访问逻辑、填充实体类）。
数据访问 简单说就是 SQLHelp ，
访问规则 就是处理SQL语句，或者是存储过程，以及填充记录集的问题。
数据访问 解决如何访问数据库的问题，（侧重于数据库，比如多种数据库的访问等）
访问规则 解决访问哪个表，提取哪些字段，查询条件是什么，等等这些问题。（侧重于逻辑，需要哪些字段，不需要那些字段，要不要分页提取数据，还有添加、修改数据，删除数据，统计查询等）
[解决办法]
up 长见识了
[解决办法]
个人认为还是业务层吧，最好用存储过程，sql考虑安全因素麻烦
[解决办法]
说到底界面只是访问数据库的接口，所以我觉得根本的业务还是通过sql实现，其它的部分可以对业务逻辑进行验证，拆分等其它处理。其实放哪一层都无所谓，关键是合理，怎么方便怎么做。当然方便包括以后维护的方便。
[解决办法]
关注ing
对于三层也是有点疑惑
[解决办法]
我认为只有where 后面的算。
我经常就是传递where 语句到DAL的
[解决办法]
有意思的问题，个人认为放在数据层，实体对象应该包含该对象的所有属性，这样当增加显示字段的时候，只修改数据层和UI层就可以了。
[解决办法]
sql 语句放在业务层
数据层就是访问数据库的通道 他不用关心 具体执行什么样的CRUD操作
[解决办法]
不知道楼主所说的是不是跟我类似,或者是两马事,看看这篇
http://community.csdn.net/Expert/topic/5456/5456736.xml?temp=.4981043
[解决办法]
再或者看看下面这篇
http://community.csdn.net/Expert/topic/5169/5169703.xml?temp=.7816278
[解决办法]
个人理解 说错勿怪
=======================
逻辑层 含 业务逻辑和规则逻辑 写在一起也可以
"假设现在要增加一个信息，要显示产品的产地。 明明是业务逻辑的变化，我们为什么要改数据层...... "
逻辑层不是处理这个变化的
应是 例如：一个留言板 每天最多发100条回复 多的话提交不了 这个控制应该放在逻辑层 因为他没有改变数据库 只是业务逻辑的改变
而你上面的改变是改变了数据库了, 实体模型、数据层都应改变
如果还需要在前台显示的话 当然需要改表示层了
我们也经常遇到增加数据字段 而前台不需要显示的时候 如状态字段等等
这时就不用改表示层了
[解决办法]
你要先了解三层主要是干吗用的,就很明白了
比如你要用ACCESS2000和SQLSERVER2000数据库.那么请问你将存储过程放在哪里呢.
如果是SQL语句那么select @@identity之类的语句你放到业务层，ACCESS2000能执行成功吗？
所以不要混淆公共数据库操作类和三层
------解决方案--------------------
你并不能寄希望于业务改变了，就不需要你修改数据层了。
你首先要弄清楚业务层和数据层的关系。
数据层都是对数据的原子操作，原则上来讲不能称之为业务，但是如果一个业务明显只有一个原子操作的话，自然你会认为这也是一个业务，这里它们只是概念的区别。
[解决办法]
jyk(今天由我来写的代码，明天就让程序自己完成！喜欢编程) ( ) 信誉：100 Blog 加为好友 2007-04-30 09:37:52 得分: 0
to：michael556cdj()
我们的想法比较像，有空详细探讨一下。
jyk.cnblogs.com 我的blog，有我的数据访问的代码。
当然 SQL语句放在业务层也是有问题的，还数据库了怎么办？能保证所有的SQL都是通用的吗？
通用的话就不能使用数据库特有的，也就是说不好保证效率，比如 top 10 在Access里面就会有不同的解释，Orcale里面没有top ，但是在MS sql里面top 是很常用的。MS SQL不用top 的话，用什么方式来代替呢？
---------------------
数据库通用并不是指的完全使用它们的交集，至少一部分要进行个别处理。如果你使用过通用框架，应该会注意到这一点。
[解决办法]
jyk(今天由我来写的代码，明天就让程序自己完成！喜欢编程) ( ) 信誉：100 Blog 加为好友 2007-04-30 09:31:29 得分: 0
一开始就把产品的所有属性都加上吗？介绍也加上？不用介绍的时候也把介绍提取出来，是不是比较占用资源呢？
还要考虑一下效率的问题呀。
--------------------------
很多框架都是这样做的，至于效率，你可以指定是否调入。
[解决办法]
大多数情况不同,根据你方便而定.因为后期如果有个需求要增加一个按钮,那么你的每层都要改动,所以怎么方便怎么弄.
[解决办法]
jyk(今天由我来写的代码，明天就让程序自己完成！喜欢编程) ( ) 信誉：100 Blog 加为好友 2007-04-30 09:56:02 得分: 0
to:flyforlove(有车有房，营养不良。)
> > 不能称之为业务
但是确是和业务相关的。
---------------------
严格来讲，什么都是和业务相关的，但是是不是业务，不能从它的表象上来看，很多时候业务层只是简单的调用数据层的一个方法，因为业务逻辑只有一次数据访问，你可以说它们执行的是完全同样的东西，但是业务层执行的是业务，数据层执行的只是没有业务意义的一次数据访问。
> > 至于效率，你可以指定是否调入。
在那里写是否调入的代码呢？select不变的话，都已经从数据库里掉出来了呀，再来判断还是占用资源的。
为了应对变化，很多时候实体是不变的，而改变的是它的内部数据。这个时候就不能简单的自己去写select了，需要自定义组合，hibernate就是这样做的。
> > 很多框架都是这样做的
这个不是理由吧。好多人都的了流行感冒，那我也的一下吧。
------------------------
很多人都流行感冒不是没有理由的，关键是你是否知道这个理由。
[解决办法]
很多时候3层框架并不是有用，比如很多业务逻辑只是一次简单的数据访问，这个时候，完全可以把业务层和数据访问层合并在一起，没有必要为了拆分而拆分。
有些时候，3层又是不够用的，于是延伸出4层5层来。
我前一个项目，就是因为显示层很负杂，于是在显示层和业务层中间又添加了一个facade层。
[解决办法]
我比较喜欢这种形式（UI+DAL）做项目，当然也只是小项目。
DAL中基本是getXXXX,saveXXXX,deleteXXXX，再加个SqlHelper
UI想得到什么就去DAL中getXXXX一下，想保存什么也去saveXXXX一下
这样一来，有些业务放在UI中，也就是xx.aspx.cs文件中，也有小部分放在DAL中
呵呵，我这个属于2.5层结构吧！
[解决办法]
和我的一个贴子讨论的问题有些相似，请参看一下：
http://community.csdn.net/Expert/topic/5487/5487711.xml?temp=.5016901
[解决办法]
MVC的特征在于，显示和逻辑的分离，显示的逻辑在C，而业务的逻辑在M，V中不应该存在任何的逻辑
[解决办法]
放BLL的好，DAL还是基本数据操作吧～
[解决办法]
密切关注次类问题...................
[解决办法]
你要先了解三层主要是干吗用的,就很明白了
比如你要用ACCESS2000和SQLSERVER2000数据库.那么请问你将存储过程放在哪里呢.
如果是SQL语句那么select @@identity之类的语句你放到业务层，ACCESS2000能执行成功吗？
所以不要混淆公共数据库操作类和三层
[解决办法]
当然 ，如果做项目，我认为，项目经理或架构师会把一切需要的字段都先列出来，不需要 后来在改动。。。。。。。。。。。。
但是，也不可否认， 如果要修改的话，那么，一般我就是两个层都改的，呵呵， 还不知道有什么好方法， 随便也学习哈。
[解决办法]
sunzhong2003() ( ) 信誉：100 Blog 加为好友 2007-04-30 10:12:06 得分: 0
你要先了解三层主要是干吗用的,就很明白了
比如你要用ACCESS2000和SQLSERVER2000数据库.那么请问你将存储过程放在哪里呢.
如果是SQL语句那么select @@identity之类的语句你放到业务层，ACCESS2000能执行成功吗？
所以不要混淆公共数据库操作类和三层
-------------------------------
没人混淆数据库操作模块和dal的关系。
至于要不要三层，是由实际业务决定的。
在很多需要速度，以及安全的应用中，sp是很有必要的，再者，没有什么应用需要频繁的更改数据库，所以这是个伪命题。
[解决办法]
UI,BLL,DAL 是基本的三层结构。
如果实现多个数据库，则变成这样：UI,BLL,IDAL,DALFactory[sql,access,orcal...多个实现]
想对BLL复用的话，sql语句是不能放在这里的。对应的业务逻辑要在DAL或存贮过程里各自实现。
[解决办法]
推荐的方法是三层结构Sql语句应该放在DAL中，你应该在DAL中创建DataAdapter并且设置多种灵活的方法，而且DataAdapter的方法是可以手写代码开扩展的。
关于ASP.NET的结构，强烈推荐看Scott Mitchell的文章《ASP.NET数据指南》，位置在http://asp.net英文版首页。
[解决办法]
jyk(今天由我来写的代码，明天就让程序自己完成！喜欢编程) ( ) 信誉：100 Blog 加为好友 2007-04-30 10:16:29 得分: 0
好比我到你家作客，你给我倒了一杯水，我表示感谢。
如果我把这杯水都喝了，那么这杯水就没有浪费；如果我没有喝，或者只喝了一点，那么剩下的水就浪费了。
可能你根本就不在乎，但是浪费了就是浪费了。
好多框架都这么做？为什么呢？
1、框架嘛，考虑的事情就很多了，为了更广泛的使用，就牺牲了一些效率。
2、不想因为我说的那些变化而改来改去，同样还是以牺牲效率作为代价。
3、设计架构的人一般不会想到太多的细节，一般的架构也都不是以网站为出发点的，也不是专为网站而出现的。而我说的这个是网站的问题，也就是说我只想考虑网站，而不考虑项目。
----------------------------
效率和通用性一直是矛盾的两方，其实你自己都走入了矛盾的漩涡，明知道3层架构不是用来解决所有问题的，你为什么又偏偏要使用它呢？
sql算不算业务？
这取决于你是否能够正确理解什么是业务。
一条简单的selete * from table，在有些应用里，也许一个完整的业务请求就是这么一条。
但是在很多业务请求里他却只是一部分，所以你不能简单的那这条语句来问，这是不是业务。
我还是那句话，是业务还是数据访问，不能从形式看来，要从概念上来看。
至于你说的一本水的比喻，折衷的方式是，我只给你杯子不给你水。
[解决办法]
LZ没结贴把！
没结贴的话我来说下自己的观点！标准的三层架构其他把很多都涵盖进去了！就如LZ说得那个
另外建议不要想着做一个实体类可以包含所有的变化，因为往往变化是很快的，很超乎想象的。
在把上面的例子复杂化一下。
原来的要求：显示产品名称、产品编号、价格。
第一次修改：显示产品名称、产品编号、价格，再加上一个产地。
再过几天发现只有原价不够吸引人，再加一个现价吧，就是打折后的价格。产品名称、产品编号、原价格，折扣价，产地。
又过了几天，发现产地没有什么用处，去掉吧。
又过了几天，想把产品的介绍加上。
又过了几天。。。。。。
这样你的实体类怎么设计呢？
如果不怕麻烦细分下我想大家就能够看明白了！我再下面把三层分成了七层
[解决办法]
对于LZ说得那些基本的属性我们可以直接放到一个实体层全名叫(businessEntity)
他包括所有的实体那么你要显示产品的名称什么的我就不需要去该查询语句了
我再buinessLogic层直接返回一个entity的对象那么我需要什么就可以直接拿什么
忘记说是分哪7层了
1.BusinessEntity
2.BusinessInterface
3.BusinessLogic
4.DataAcessFactory
5.DataAccessSQLServer
6.DataAccessTool
7.UI
我这么写的话估计应该能看得懂了
[解决办法]
TO楼主：三层架构不能用来写网站吗？只是为了更换数据库吗？没有看得太明白您说的，所以没有回复。
我可没这个意思。这里说的架构跟写网站无关，虽然petshop是B/S结构的。如果你想更好的数据迁移，你可以选择三层模式。但是你如果存储是把SQL写在BILL里你就不是petshop提倡的三层了！那么你这个也就是介于两者之间，我习惯称为2.5层。也就是从一开始数据库的类型已经确定。所以写个数据库操作类，一切都在业务层里实现。显示层调用和使用三层是一样的。
[解决办法]
我想根据写法就应该知道每个层是干嘛的！我就不罗嗦多做解释了！
作用的话我觉得每个层的功能都很清晰了。
[解决办法]
在三层结构中，SQL 语句包括存储过程应该是放入到“数据访问层”！
中间服务层是不与具体的数据访问层发生关联的，并且数据访问层不应该参与具体业务逻辑计算
数据访问层的操作应该是原子操作！
这样便保证了“业务逻辑”与“存储逻辑”的不相关性！
jyk 你所说的是修改“实体”属性，而不是业务逻辑。
另外，N层架构多数流行于大型项目的开发过程中，因为这样做可以令程序员各尽所长
最后，再作一个广告：
《浅谈“三层结构”原理与用意》 下载地址：http://www.bincess.cn/Downloads/MainDoc.rar
欢迎登陆彬月论坛(http://www.bincess.cn/)，呵呵
[解决办法]
有兴趣可以去看看Dude, where 's my business logic?http://www.codeproject.com/gen/design/DudeWheresMyBusinessLogic.asp
先说明是全英文的。。：）
[解决办法]
KingDemo() ( ) 信誉：100 Blog 加为好友 2007-04-30 10:29:20 得分: 0
对于LZ说得那些基本的属性我们可以直接放到一个实体层全名叫(businessEntity)
他包括所有的实体那么你要显示产品的名称什么的我就不需要去该查询语句了
我再buinessLogic层直接返回一个entity的对象那么我需要什么就可以直接拿什么
忘记说是分哪7层了
1.BusinessEntity
2.BusinessInterface
3.BusinessLogic
4.DataAcessFactory
5.DataAccessSQLServer
6.DataAccessTool
7.UI
我这么写的话估计应该能看得懂了
-----------------------------
你这个都敢叫7层，那随便都能写出个10几层来。
[解决办法]
当然不算了啊，如果算的话也算是数据层的逻辑，比如说存储过程
推荐一些Asp.net三层的源码给你
http://www.51aspx.com/Tags/2
[解决办法]
flyforlove(有车有房，营养不良。) ( ) 信誉：100 Blog 加为好友 2007-04-30 10:34:45 得分: 0
KingDemo() ( ) 信誉：100 Blog 加为好友 2007-04-30 10:29:20 得分: 0
flyforlove(有车有房，营养不良。)
对于LZ说得那些基本的属性我们可以直接放到一个实体层全名叫(businessEntity)
他包括所有的实体那么你要显示产品的名称什么的我就不需要去该查询语句了
我再buinessLogic层直接返回一个entity的对象那么我需要什么就可以直接拿什么
忘记说是分哪7层了
1.BusinessEntity
2.BusinessInterface
3.BusinessLogic
4.DataAcessFactory
5.DataAccessSQLServer
6.DataAccessTool
7.UI
我这么写的话估计应该能看得懂了
-----------------------------
你这个都敢叫7层，那随便都能写出个10几层来。
--------------------------
我说的不是指物理上的7层把！我只是把3层分细了！
在逻辑上说基本只有3层的概念！
如果往细分你想怎么分都可以！
[解决办法]
正感到对此类问题没有什么好的解决方案，，，
看了此贴长见识了，，继续关注
楼下继续，
[解决办法]
LZ提出的问题我还是觉得是逻辑层的处理！
因为不管你是要返回多少个属性我只要把一个实体在逻辑返回来就可以得到！
何必去改SQL语句！
而且SQL语句你完全不要写死出多少个属性的。
[解决办法]
KingDemo() ( ) 信誉：100 Blog 加为好友 2007-04-30 10:39:01 得分: 0
flyforlove(有车有房，营养不良。) ( ) 信誉：100 Blog 加为好友 2007-04-30 10:34:45 得分: 0
KingDemo() ( ) 信誉：100 Blog 加为好友 2007-04-30 10:29:20 得分: 0
flyforlove(有车有房，营养不良。)
对于LZ说得那些基本的属性我们可以直接放到一个实体层全名叫(businessEntity)
他包括所有的实体那么你要显示产品的名称什么的我就不需要去该查询语句了
我再buinessLogic层直接返回一个entity的对象那么我需要什么就可以直接拿什么
忘记说是分哪7层了
1.BusinessEntity
2.BusinessInterface
3.BusinessLogic
4.DataAcessFactory
5.DataAccessSQLServer
6.DataAccessTool
7.UI
我这么写的话估计应该能看得懂了
-----------------------------
你这个都敢叫7层，那随便都能写出个10几层来。
--------------------------
我说的不是指物理上的7层把！我只是把3层分细了！
在逻辑上说基本只有3层的概念！
如果往细分你想怎么分都可以！
---------------------------------
3层细分出来的就不能是层了，只能算是你这一层的结构组合。
你可以把它叫做模式。
[解决办法]
KingDemo() ( ) 信誉：100 Blog 加为好友 2007-04-30 10:41:38 得分: 0
LZ提出的问题我还是觉得是逻辑层的处理！
因为不管你是要返回多少个属性我只要把一个实体在逻辑返回来就可以得到！
何必去改SQL语句！
而且SQL语句你完全不要写死出多少个属性的。
-----------------------
效率的问题不能完全不考虑，如果有多重的主从关系的话，效率会很低的，现有的解决方法是用lazy load，但是字段的问题确实很棘手，有的解决方法是实体有这个属性，但是没有数据。
[解决办法]
Top
flyforlove(有车有房，营养不良。)
3层细分出来的就不能是层了，只能算是你这一层的结构组合。
你可以把它叫做模式。
-----
您说得是由道理不过应该也不叫模式把！在设计模式里面好像没有属性的概念！最多就说说是我们设计出来的类把
------解决方案--------------------
应该算数据访问层，介于业务层与数据库之间！
不过现在很多人都用数据实体层来取代数据访问层了！
