ASP.NET多层结构

三层架构
表示层
业务层
逻辑层

我觉得主要是DAL的效率，这个层应该用COM实现，但是这样的话，如果是DNA的防火墙又成了问题。

还有，分层后的资源释放问题。

BLL层的只放逻辑规则就可以了，用它来连接UI和DAL

业务逻辑层(BLL)：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理。如果说数据层是积木，那逻辑层就是对这些积木的搭建。
数据访问层(DAL)：主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务。
(IDAL)它体现了“抽象”的精神，或者说是“面向接口编程”的最佳体现。抽象的接口模块IDAL
(Model)实体和数据库表映射类
（Web）web网站项目

就按你的要求写把
需求：
1。需要有一个对象负责接收key
2.改类需要查询数据
3.该类需要返回数据

约束：该类在实际使用中需要查询商品表

C# codepublic class seach
{
private string _key
public string key
{
set(_key=value;)
}
private object _Result;
public object result //返回值，这里使用object是为了留出空白，保留该类的变化
{
get
{
return _Result;
}
}

public virtual void getSearch() //查询数据，这里使用virtual同样是为了留出空白，保留该类的变化
{
}
}

你可以看到这是一个纯粹的对象，没有做任何数据库要做的事情，也没做界面要做的事情，他完全是对需求的一个代码翻译
这个是实际上是MOdel的东西

2.有了model层，我们在做业务逻辑,业务逻辑我们要完成对这个对象的约束

C# codepublic goodsSearch:seach
{
public Dataview seachRes //返回结果
{
get(return (DataView)_Result;) //这里我返回了DataView,实际上你可以返回别的东西，只要你能转换的过去
}

public goodssearch(string key)
{
_key=key;
}
public override void getSearch()
{
_Result=DAl.xxx(_key)//去数据层取数据，当然数据层怎么写是数据层的事情，这里就不要关心了
}
}

3.数据层，这个我就不写，基本就是把你自己写的访问数据库的东西在写一遍，你明白就可以了

现在你可以看的比较清楚了把，实际上三层的模型完全就是在将就对象设计，而在对象设计初期，我根本就没管数据库和界面的事情

实际上的区别在于考虑问题的方式，就PetShop而言，从界面层考虑，他的业务逻辑层没问题，完全合用，数据层也没问题

问题在于：PetShop根本就不是开始从界面层考虑问题，他一开始就是从model层开始的，所以最终表现成了现在的架构。

所以，你该把你的眼睛放到model层，由model层看其他层的东西

这个东西，我可以毫不客气的说（我不怕得罪人）建议看petshop的，而没点出为什么要看PetShop的人，实际并不明白为啥要分层。对于这些人，我说是马后炮，中国队赢了，你们说中国队战无不胜，中国队输了，你们说中国队就是一群“猪”

将DataLayer放在App_Code文件夹下他还是业务逻辑层，不管你把它放到哪，都是业务逻辑层，软件分层在于思想和归类，而不在于文件摆放的位置。
数据层：一般只包括数据库那块，而且也不包含大量的存储过程，按照数据层的概念，就是提供简单的数据存储维护任务的。
逻辑层：一般就是指我们写的程序的逻辑处理部分不包括界面。这个其实很难区分，例如数据访问层根数据层容易混淆，其实我明确不了它算什么，还有网上流行的数据持久层也就是被称为ORM的大型框架，按照理论来讲它大部分功能应该是属于数据层的应该划为数据层，但是实际架构中又与数据库没密切联系，所以有人把它分离出来叫数据持久层，我觉得在软件开发中没必要非得用这么大规模的框架做性能缓冲，那还不如用多个数据库软件做，小型的数据缓存，可以通过其它缓存方式来解决。但事实表明中国人都是很懒的而且很想节省开支，所以很泛滥的在用这些东西，从而也导致了中国软件性能的各种问题，“慢”是一个最明显的问题。数据方面的逻辑处理的方法就属于这层，如果这样说的话，复杂的逻辑存储过程其实也是属于这层的，用一两个倒没什么，最让我难以理解的是，大部分人大部分公司都在以各种程度的滥用数据库的存储过程，一个很小的处理都用存储过程写，这到底能给你带来多大的方便呢？如果改动你也不可能只该存储过程还是要改程序，而且这样做无形的就给数据库增加了一层压力，这也是为什么大多数软件程序还为垮，数据库先垮掉的一个原因之一。
表示层：其实就是用户界面了，这些基本的控件操作阿，什么的都是。

以上仅为个人经验所得，仅供参考，我也希望中国软件界多一些能自我开发的人才，而不是只能用一些成熟的框架做二次开发的人才。拿来的东西是未必都很好用，要充分了解它的特性，有选择的使用。

ASP.NET多层结构
作者/发布者:流水

实际 PetShop4是三层扩展出来的，用七层模拟做了两个小项目，实际和三层没区别，只是多了反射和接口。但是项目强壮了很多，可以顺利过渡任意数据库可以灵活切换数据库不改源码，很好的实现了OCP原则，至于上层换BS或换CS 分三层就能够灵活实现，所以对七层的理解很重要.

所以我上面说能把三层讲清楚就不容易了...

factory和ioc是什么？请去查清楚概念再想想它们和分层的关系...

分层是一种工程方法并非开发技术...

举个不太恰当的例子：
我现在穿T恤+牛仔裤+休闲鞋，当然我还穿内裤和袜子，然而所有人都知道我这身装扮的架构是上衣+裤子+鞋...没有人会拿自己的内裤出来炫耀...
天气再冷一些我会再加外套，更冷的时候我会再加保暖内衣...需求变化了，然而它的架构依然是上衣+裤子+鞋...
如果我去寒冷的北方会再加毛衣和大衣鞋子也会换成靴子袜子可能穿两双，如果我去登珠峰我会加更多更专业的御寒装备，需求变化导致我扩展我的架构...然而它的架构依然是上衣+裤子+鞋...不管我穿了多少条裤子它们只有一个功能——保护我的下肢——我认为它们是一个层次的东西...

其实我感觉在分层的意义上,可能各个人对层的深浅不同，所以出来的层也不同吧.

如果:

裤子 = 保护下肢
裤子+鞋 = 保护下肢
上衣+裤子+鞋+ 两双袜子 = 保护下肢

如果说以上三个选择是一个层次的东西,那退一步来看,穿着的基本功能都是为了保暖的,上衣+裤子+鞋是不是可以看成是一层(因为功能一致)呢?

分层的概念:分层表示将功能进行有序的分组.

我觉得当鞋或袜子加入时,它们的功能与裤子是不同的,于是,将他们的功能进行分组是可以出新的"层的",这样分层有多了一层.

我觉得架构和分层还是有区别的.

工程方法是从实践中来到实践中去，是为了解决实际问题的...

化繁为简见功夫...化简就繁是庸才...

逻辑层和物理层不是一回事，一个项目只是一个物理上的概念，不是逻辑上的。

分层的目的
为了多人开发方便

1 开发 个人开发，我想怎么开发怎么开发，那是我的问题,分不分层无所谓的事情
多人协作开发
一人开发一个模块，各不相干的开发,那么模块之间的调用肯定是接口最恰当了

2 布署
布署你把bll.dll和model.dll放到二个服务器上.这，显然不恰当 ,那么分布式布署也仅仅是说web服务器和数据服务器不在同一服务器上

3 维护
如果bll出了问题那么我们更新一个bll然后再上传这个dll，显示是很方便的
事实上,就面对对像来说如果某一类某一方法出了问题,一般的解决方法是重写子类或是再继承一个类重写掉 这样不会影响其它类， 这就要求我们在开发时候一定要规化好类层次

事实上,分层主要是分类的层次,主要是为了方便维护和管理

一个程序员写出来的程序不能扩展，不能改良，这个程序员只能是代码工人啊， 苦口婆心，绝对没有伤人的意思。 可以看看一些分层的开源项目，对自己绝对没有损失。

并不是每个系统都要分层，一般只针对一些大型系统才采用分层，你看PetShop4，总共有22个项目。
大体思想是3层，从Model,DAL,BLL，

然后他在各层上又采用了工厂模式，把逻辑与实现想分离，比如以前BLL直接调用DAL就好了，
但现在BLL却调用了IDAL,IDAL只是一个接口层，里面封状了要完成的一些业务逻辑，
而具体的实现则交给DAL去实现，
然后借助于工厂模式DALFactory和映射完成IDAL层中类的实例化。

这样不管我们用的底层用的是什么数据库都可以完成BLL对DAL的调用。
另外，从分层角度来看，你的分层至少也不标准。
首先你不应该将那些SQL语句放在BLL层中，而应该是由DAL层来完成和数据库的交互。

要想研究分层模式，PetShop4的确是一个相当好的例子，值得学习。

在.NET中 DAL+IDAL+Model+BLL+Web是什么意思

业务逻辑层(BLL)：主要是针对具体的问题的操作，也可以理解成对数据层的操作，对数据业务逻辑处理。如果说数据层是积木，那逻辑层就是对这些积木的搭建。
数据访问层(DAL)：主要是对原始数据(数据库或者文本文件等存放数据的形式)的操作层，而不是指原始数据，也就是说，是对数据的操作，而不是数据库，具体为业务逻辑层或表示层提供数据服务。
(IDAL)它体现了“抽象”的精神，或者说是“面向接口编程”的最佳体现。抽象的接口模块IDAL
(Model)实体和数据库表映射类
（Web）web网站项目

1.兵无常势，水无常形
2.吾常闻拙速，未尝闻巧以久也
3.运用之妙，存乎一心

形式真有那么重要吗？？世人皆称 二万五千里长征是奇迹，但这个奇迹是一个无奈的奇迹，是需求和条件决定的，你会无缘无故的去做二万五千里长征吗？？

三层开发
我想到我以前对其的理解 也只是数据,逻辑,表现
但如何区分它们,实在太难
后来,对其深入的思考 数据层 不过是从数据库取出数据,
逻辑层是逻辑的实现功能,表现 就是 呈现出来.

有一个方法区分用多少 就是上楼模型.
你必须从一楼一楼上,不可跨越任何一层.
如:当你从一楼到二楼,不论你走那个楼梯,都可以到二楼,
这些楼梯可以看作一层.

分层是工程方法...

设计模式也是工程方法...

工程方法的最终目的不是技术层面的东西而是TCO...从纯技术的角度去理解分层永远都是纸上谈兵...

我写过七层的模块,有过两次,
我们大部分开始构架的时候是五层,然后再整理分析七层就出来了,
没有什么乱的啊,感觉很好,方便调用.不像楼上有些人说的那样[把问题复杂化了].
项目较大的,我想七层是最好的选择了.

三层
UI层
逻辑层
数据层
已经很经典了,当然不是我说了,但是里面还是可以继续分的,主要是为了开发便利.

7层没什么,很正常. 只是楼主没真理解7层,实际上所谓7层还是3层!! 无非是分的更详细些,比如提供了接口层,实体层(参数数组)等等

七层是正确的，这帖子讨论的时候我还没开始分析PetShop。

实际 PetShop是三层扩展出来的，用七层模拟做了两个小项目，实际和三层没区别，只是多了反射和接口。但是项目强壮了很多，可以顺利过渡任意数据库可以灵活切换数据库不改源码，很好的实现了OCP原则，至于上层换BS或换CS 分三层就能够灵活实现，所以对七层的理解很重要，如果鄙视技术思想还做技术做什么，不用就不用，用不着站着说话不腰痛。

factory 独立出来 主要是为了直观，分七层 如果接口和方法都定义好后，任何一个有基础的程序员都可以参与大型项目。 项目风险降低很多，节约很多时间。

层，无所谓有，无所谓无

层在心中，层的最高境界是 无层

---DBUtility数据层基类
---DALFactory数据层工厂类
---IDAL接口层
---SQLDAL接口实现层
---Model实体类
---Logic业务逻辑层
---Web表示层
友情合作伙伴：第一网络（http://w1.org.cn）！本文出自：http://w1.org.cn/web/programming/layer3.html

跟随商鞅的脚步...