问题描述
可以简单理解成：在设计那儿拖控件，如何在控件事件处写·方法·吗？
解决方案
解决方案二：
拖控件，事件处写方法还能叫三层结构啊？还是先去看看什么是三层结构吧
解决方案三：
所谓三层结构，就是有“业务逻辑层”的结构。只要是有一个业务逻辑层来屏蔽掉数据库的结构，就是三层结构。你开发程序时，使用你的开发工具提供的“中间层”——数据绑定控件，或者使用你的开发框架提供的数据中间件——远程数据服务，这些都是三层的提现。在开发asp.net程序的过程中，虽然调用数据服务的接口，但是不纠结于数据库是哪一种、保存在哪儿、是一个数据库还是3个数据库来保存数据。自顶向下地分成三层，是以表现层设计为出发点来设计业务逻辑层接口、将数据操作层与表现层彻底分离，而不是自底向上地拼凑。这是一个工程方法，而不是纠结于用什么控件、用什么编程语言。
解决方案四：
对于一个号称是“三层”的框架是不是真的三层结构，这最容易从工程的“贴合程度”上看出来。假设一个项目组，它们的数据服务中间件、服务层、数据绑定控件的接口设计定义，是从数据库表的结构定义出发来设计的，那么他们往往就是一个非常“假”的三层。理由某些自称为三层结构的所谓“生成器”，它连用户的表现层需求都不知道、业务逻辑层都不知道，它根据数据库表就号称产生了什么“业务逻辑层”，那么这种生成器就显然是和扯淡的三层代码生成器。可以肯定地是，它产生的就是数据操作层代码，也就是人家用ORM、EF甚至SqlHelper原本轻松操作的东西，它给再次封装了两层，然后给了一层“薄薄的”所谓的业务逻辑层，只是去调用数据操作层代码，而没有真正的业务逻辑层的实质。因为它根本不可能自动产生业务逻辑层，业务逻辑层设计接口是需要从分析大量前端表现层界面交互流程才能粹取出来的，而不可能从数据库表就拼凑出来的。因此实际上三层代码也很简单，就是坚持一个观念，让你的不同的产品、不同编程语言、不同通讯平台（例如pc页面跟手机app的差别）最终都用同一个数据服务系统（或者类库），而不重复地写两套东西。一个公司假设有50个产品，那么它的业务逻辑系统可能只有1、2套，而不是重复写上50套业务逻辑层软件。“三层”就是一个保证这种工程结果的手段。它让千变万化、随时重构的前端表现层，能够用上稳定和通用的业务逻辑层。
解决方案五：
“三层结构”有无数种体现的方式。它是世界上最简单、最基本的软件项目分层方式，所以其实并没有固定的模式。根据基本的理论，你能区分、判断这些分层有没有真正达到分层设计分层开发的目的，这就行了。比如说，从asp.net框架开始提供了membershipprovider框架（一个abstract的类库，以及1、2个作为示例的现成实现的类型），它是为了有关用户、登录、角色权限判断功能而抽象的功能中间件，然后你可以继承它并且扩展底层的自定义数据操作。这样不同的项目，甚至不同的平台（不管是asp.net还是wpf的应用）都可以调用你们自己相同的一套用户授权管理接口。从大量前端应用中抽取出这个功能的业务逻辑层，抛开表现层，屏蔽数据层，用它的目的就是在相关的开发中去进行三层设计和开发。
解决方案六：
三层架构吗？model--dal--bll当然，还有view。model就是数据实体层。dal只是对数据的进行增删改查（没有业务逻辑）bll带有业务逻辑，也就是多个dal层的方法的综合调用（解释的可能不太正确，反正就是对dal获取到的数据，进行业务逻辑的处理）view层获取bll提供的信息然后展示
解决方案七：
个人的一点体会，仅供参考。之所以分层，是因为随着系统规模的扩大，复杂性的增加，需要对程序的组织进行一定的规划、设计。比较好的方式是系统从无到有，从小到大，在不断的升级过程中体会。刚开始，拖控件、写后台。慢慢发现前段页面会有些逻辑上的共性，比如：根据ID获取对象内容，判断用户是否符合某权限等等。这是可以把这些共性的逻辑功能写成类库，由前段调用。慢慢地，又发现逻辑功能里面有些对数据库的操作也是相同的。就可以把单存的数据库的操作独立出一个数据库操作的类库。其实分层，分几层都没有固定的，还是根据系统因地制宜比较好。个人的一点体会，仅供参考。欢迎交流！