.net 三层架构
在网上看到简单的三层架构如下：
DAL:数据访问，调用sql   help基类,一个类对应一张表的操作，add   insert   update
Model:实体类
BLL:业务逻辑
WEB:表示层：

请问：
Model所其的作用是什么？不太明白.
BLL什么也没做，只是调用了一下DAL中的方法(仅一句)，WEB中又调用BLL,为什么不直接在WEB中调用DAL中的方法?
每张表对应一个类，如果需要多表连接查询，怎么办（在这种架构下）?

我一般的做法：(也分三个项目,架构方面没什么经验)
数据操作：相当于sql   help
业务：具体的一个方法，如通过sql查询出结果放到一个datatable中，所有方法全部是自己手写的，如果每张表一个类，我想有些表我不一定需要操作，再者，连接查询时，用不上，所以都是手写；
web:调用上面的，把datatable绑定到页面控件

请问我这种做法在项目中会不会有什么问题


------解决方案--------------------
Model:实体类

你看了应该明白,它相当于数据库表结构在程序中的一个映射.

对一个实体类实例的操作就相当于操作一条数据表记录.
他的作用是起到了各层之间数据传输对象的一致,相当于一种协议.
------解决方案--------------------
BLL的作用相当于DAL层的一个代理,他的好处是,对DAL的重构,不会影响web层．
另外，有些业务比较复杂的系统，需要在BLL中进行一些运算，即一个BLL类中的内容，可能是由多个不同的DAL数据而来．
------解决方案--------------------
web调用datatable没有什么错．但分层开发时，web层的人员知道你的datatable是什么内容吗？
所以这时候，他还是需要和DAL层的开发人员打交道才能够知道．

如果这时候的数据返回使用实体类的集合，那么他就不用向DAL开发人员询问．这时候系统会更严格更标准．因为数据返回有了一个明确的格式定义．
------解决方案--------------------
分层的优点
使用面向对象的多层结构进行开发，可以使系统结构和功能逻辑清晰明了，便于系统模块的拆分组合，让项目组成员容易明确项目目标，获得清晰的分工和责任，使整个程序开发过程有序可控，同时清晰的架构分层和模块划分，也是各对象间相互独立，保证了系统的可维护性和可扩展性，也便于开发人员在开发过程中及时发现错误原因，迅速明确错误位置，保证单元模块的开发质量，降低了导致系统集成错误的因素。
其实分层就跟你在一个类里面写方法的道理一样，如果一个方法太大，包含了太多的逻辑，肯定会让人摸不清头脑，所以，你就有可能把这个函数重构，会把这个大方法分成几个小方法，一来你的代码清晰了，自己和别人好看。二来重构出来的方法有可能给别的地方调用。
如果你觉得你的项目需要分层，就分层去做，否则就别分层。分层的主要目的就是为了降低维护成本，提高代码的可重用性，降低耦合度。层与层之间的分开有利于梳理信息流，同时也有利于分配任务。千万别为了分层而分层，那样会越分越乱。譬如，一个小型留言板，有必要分层吗。主要还是看实际需要。

每张表对应一个类，如果需要多表连接查询，怎么办（在这种架构下）?
可以再加一层Entity
DAL:数据访问，调用sql help基类,一个类对应一张表的操作，add insert update
Entity:(特殊)数据访问，调用sql help基类
Model:实体类(数据库表对象)
BLL:业务逻辑 调用DAL或者Entity类
WEB:表示层 调用BLL类