调试易

关于多层的概念，可能每个人的都不完全相同。
如果数据库和服务器端都在同一部机器上，
那么 Web Service 我也认为没有什么必要。数据库＋Web应该程序，我倾向你的观点，
那不应该算多层。如果非要给什么是多层定立一个标准的话，
Duwamish7 是个很好的参考。

你的主管对多层结构的了解太肤浅了。》我们的技术主管说：开发多层结构的网络服务程序没有什么用，不如用直接
》用ASP.NET开发Web应用程序。请你的主管看看VS.NET带的例子Duwawish7.微软借用asp.net,和ado.net的优势把系统的层次划分的清晰，有序，在这种项目组中工作，会让你感到一种艺术的魅力。我个人认为多层应用是OO思想的一种延伸，一种最好的实践。如果系统的划分不是OO的，系统的层次划分的越细，可能麻烦就越多。用OO的思想划分层次，哪怕是开发简单的桌面级应用，甚至是不设计数据库的应用，你多可以理直气壮的说，我的系统的多层的。

多层架构是仅仅是一种架构,他是相对c/s两层架构而言的.你所说的有windows应用程序,那其实是在早几年所提的胖客户端概念,与之配套的理论有microsoft dna等,那些都是相对与局域网系统而言.实际上即使你作web application,如果不是那种前端界面直接与数据打交道的,那就是多层结构.
也就是说如果你加了你的商业逻辑层,那就是已经构成了多层结构:
数据层+业务层+界面层

是否采用多层结构取决于项目的性质。
Web应用程序加数据库也有可能是多层应用。
例如，ASP + COM+ + SQL server
多层应用的好处是使各个应用层次隔离，性能和调试等方面都有其优点。
特别是一些做中间件的软件公司可以专门针对某一层次开发组件，提高二次开发的效率。
然而并不是任何项目都应当采用多层结构的，应当观察项目的规模和成本，技术难度等。

考虑到应用程序的可伸缩性和可维护性，那么采用多层构架就非常有必要。设想一下这样的情景：目前你公司的那太服务器已经不能满足日益增长的访问量，公司决定增加数台服务器，并采用集群技术，这时，你是重写你的应用程序还是修改呢？恐怕都不是一件容易的事。如果你采用了多层构架，你设置不用担心这个问题，简单地把各层合理地布置到各个服务器上，而无需做太大的变动，甚至不需要变动。提到应用程序的可维护性，这方面所花费的精力估计大家身有体会吧，但你用户的需求发生变化，这是你是修改整个程序呢还是只对应用程序的某层做变动？
至于Web service，我想不需要在这里做更多的说明，IBM和MS等不会对没有价值的技术投入巨大的人力、物力和财力来推行这项技术，难道他们仅仅是为了争夺市场？
你的主管如果仅仅是针对某一具体的项目而言，这可以理解。但是如果是针对公司的整个开发策略，那么你的公司的前途就危险了，一个缺乏长远目光的公司，它的命运可想而知。
推荐几篇文章，希望对你有帮助：
http://www.microsoft.com/china/msdn/library/dndotnet/html/DesignNetApp.asp（中文）
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/DesignNetApp.asp（原英文）
上面的文章可谓是经典，看看评价就知道了http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/buildntierapp.asp?frame=true（英文）

九十年代初客户机/服务器计算模式开始成为主流技术，将数据统一存储在数据服务器上，而有关的业务逻辑都在客户端实现，即所谓胖终端的解决方案，这种两层结构的模式大大阻碍着系统的发展，单一的服务器结构紧密地依赖供应商；数据存取受到限制；难以扩展到大企业广域网或国际互联网；也难以管理客户端的机群。随着用户业务需求的增长及Internet/Intranet的普及，将以三层或四层体系结构取而代之。所谓三层结构，就是在原有的"两层结构"(客户端和服务器端)之间增加了一层组件，这层组件包括事务处理逻辑应用服务、数据库查询代理/数据库等。随着这层组件的增加，两层结构向三层结构转变后，客户端和服务器端的负载就相应减轻了，跨平台、传输不可靠等问题也得到了解决。增加的这层组件就是我们所说的"中间件"。中间件在三层结构中主要充当中间层，完成数据安全、完整传输，通过负载均衡来调节系统的工作效率，从而弥补两层结构的不足。在这种结构中用户端仅仅是处理图形用户界面(GUI)，而目前趋势是采用具有交互功能的浏览器，即形成瘦终端的工作方式，为此，中间又增加了一层，称为Web服务器层，形成了四层体系结构。     这类多层结构的分布系统，各服务器和终端机之间都是通过网络连接起来的，并有大量信息和数据进行传递。对每个应用系统而言，在设计和实现时需要开发的，仅是在应用服务器上的业务逻辑部分的软件，除此之外，还必须要设计处理分布系统所特有的功能的软件，而目前的系统软件(操作系统和支撑软件)都不支持。为此出现了中间件，它是处于系统软件和应用软件之间的一批软件。使设计者集中设计与应用有关的部分，大大简化了设计和维护工作。通过五、六年的大量应用和实践，中间件已有一批成熟的产品，并成为设计分布系统时不可缺少的软件。

我们的技术主管说：开发多层结构的网络服务程序没有什么用，不如用直接用ASP.NET开发Web应用程序。          这种说法是错的，因为C/S和B/S的完全是两种模式，包括客户的
         操作，因此有必要开发多层结构的网络服务程序他还认为：如果应用程序服务器和数据库服务器都在一个机器上就没有这种必要。         这种说法查不多是对的，从安全角度出发，如果在同一个服务器上，就没有必要开发什么多层了，但是如果在这个基础上开发多层，可想而知我们可以自己做加密，包括数据库用户和密码的管理都可以更方便。还有 数据库+WEB应用程序，算不算是多层结构的？我个人认为不是，但我们的技术主管认为是。
                     可以算是多层结构，也可以算是准多层

你的技术主管说的是ASP,我他对ASP.NET都没有理解,其实即使是ASP也可以写成,也可以做到三层结构.有时候简单的引用可以是两层.而ASP.NET针对ASP最大的区别是真正的应用了OO思想,比如我们写一个简单的留言本,以下是我的程序模式,请朋友们指点.1.定义留言本类(note.cs)
class Note
{
   //此处声明所有用到的属性.   pubilc Note(){}   //构造函数   pubilc bool AddWords()
   {
        //竟当前信息添加到数据库中,实现添加留言功能
   }   pubilc Note[] GetCurpage(int iCurPage,int iPageSize)
   {
        //根据参数得到当前数据库中,特定范围的记录,实现得到特定页的留言记录,返回值,我更多的是使用DATAVIEW,此处使用了Note数组,看个人喜好而定
   }   //其他直接和数据库的操作...
}上面的结构,朋友们应该可以看出来,就是我们通常说说的数据层(我一般把数据曾写成类,供业务曾调用)2.完成了上面的类代码,下面开始写业务曾,其实,在ASP.NET下,我一般是在CODEBEHIDE中完成,在CODEBEHIDE中,调用上面的类,完成实际的发言,查看留言的等3.就是表现层了,也就是一般的ASPX代码,这部分中基本全是HTML代码,几乎不包含任何程序代码.使用三层结构的好处,是程序的维护和升级的非常容易,如果数据库变了,我们只需要简单修改一下我们的类文件,只要调用的接口没有变,那么我们可以很容易的扩充我们的程序.而如果是想变换程序的样式,那么更简单了,只要让美工修改一下我们的ASPX页面,其他的可以几乎不动就成了新的版本.....

to chinaplate
系统的分层是相对的，：）

to soholife(贝贝) :
你的note类应该属于中间层，其中的关于数据库的操作应该再抽象出来成为数据层，你所说的codebehind文件中的代码和aspx页面文件同属于表现层，否则将代码分开的aspx文件中只有静态标记，根本不能算做为一“层”。