关于三层架构，不得再说一说
今天搜索一个问题，偶然看到论坛中一篇老文，讨论得很激烈：
 不显示删除回复显示所有回复显示星级回复显示得分回复 一个关于三层里的数据层的疑惑——SQL语句算不算业务逻辑？[
http://topic.csdn.net/u/20070430/08/da7d50dc-9c7f-43a2-89a7-7a3fda613b69.html

看了之后，不得不再说一说，有很多初学的同学都存在误解，困惑，这里说一下我的总结：

1，SQL语句，只应该放到DAL层，也就是数据访问层；
SqlHelper等等对数据进行CRUD的东西，应该算作系统框架层的东西，不是三层架构中的数据访问层，可以算作“数据持久化层”
数据库，这个应该叫做“数据存储层”
2，业务层，不能有任何SQL语句出现，它是处理领域对象的，或者说是领域模型的加工厂；
3，Model，严格来说不能算作一个层，它是一个横跨UI，BLL，DAL层的东西，或者说是数据容器，BLL通过DAL将数据装进Model，然后将Model送给 UI；
4，UI，这个不用多说了，你懂的。

使用PDF.NET数据开发框架，可以很自然的理解上面的层次结构：
1，在UI层，使用Model对象和框架提供的UI控件；
2，在BLL层，使用OQL来查询Model，并进一步加工；
3，在DAL层，使用SQL-MAP来存储所有的复杂SQL查询，并提供代码工具将它映射为SqlMapDAL层代码。


------解决方案--------------------
goon
------解决方案--------------------
三层可以这样理解，但可根据实际情况可以灵活运用，比如SQL语句的条件字符串可以在业务层拼接后传入
------解决方案--------------------
学习了
------解决方案--------------------
我觉得你不需刻意的关注那一层应该具体有什么，你只要能做到隔离关注点，使得你通过业务分析出来的不同的东西能不互相影响。你就刻意任意的分层。只要做到层间耦合度低，层内聚合度高就刻意了。我觉得没有必要刻意的去说。
------解决方案--------------------
我个人的理解还是和LZ很相同的
------解决方案--------------------
model那是业务层的吧，一般认为业务层不应该和具体数据源耦合，在里面写sql明显就是不可取的...
------解决方案--------------------
个人理解
Model仅是一些实体对象 一些容器
在BLL层可以利用Model的某些实体将UI内的一些数据处理成DAL层所需要的数据形式
反过来BLL也可以通过DAL操作数据库后利用Model来将数据传给BLL BLL处理成UI所需要显示的数据 再将实体传给UI
当然这里的Model BLL DAL 都是泛指 广义上的
你也可以给各个层再细化分 比如DTO等等
------解决方案--------------------
好久木有用了，如果数据库很大的话，编译起来太慢。
------解决方案--------------------
说得不错！！
------解决方案--------------------
MVC吧 来顶一下贴
------解决方案--------------------

探讨

model那是业务层的吧，一般认为业务层不应该和具体数据源耦合，在里面写sql明显就是不可取的...

------解决方案--------------------
有些人恨不得搞个10层，其实许多部分根本没有必要一定去分层。

比如你可以使用Adapter去访问数据库，别人使用ado.net的命令方式直接去访问又有什么不可以的呢？根本没有必要对这些细节也搞什么编程“标准”。
------解决方案--------------------
pdf.net 宣传的真够厉害的，楼主觉得能干过 ef 和 nh?
------解决方案--------------------

探讨

引用:

种菜需大粪但也没必要帮助人拉屎


哥，这个是啥含义

------解决方案--------------------
以前也比较纠结Model层到底该划归哪去
后来的看法也慢慢就和楼主一致了
它可以让开发BLL层的不需要了解DAL的具体结构就能从容地处理业务，然后将结果送给UI
当然这中间为了这种方便(其实远不止方便而已），或多或少会有一些代价