linq to entity三层架构
我对用linq to entity做三层架构有点迷惑，请大家指点一下。

1. DAL层还有什么用呢？能在里面写什么东西？用页面后台代码demoEntities.DemoTable就能直接获取到表中的数据

2. 做一个简单的查询，有必要通过BLL，DAL层来调用吗？直接在.aspx.cs里面写查询语句
demoEntities.DemoTable.SingleOrDefault(table => table.Id == id);
不是更简单，不用绕BLL，DAL的圈子。

------解决方案--------------------
DAL与具体的数据库操作分开
LINQ to Entities是Ado.net Entity Framework的查询语言之一,它为了更好的兼容更多种的数据库
Linq to SQL，那就是DAL
------解决方案--------------------
BLL层的某一个方法（method)包含多个DLL层的方法时划分DAL,BLL有没有用？


比如BLL有个方法
public Method_BLL(int id)
{
if(MethodA_DAL(id) > 5 && 其他条件)
{
MethodB_DAL(); //执行DAL方法B
}
else 
{
MethodC_DAL(); //执行DAL方法C
}
}

客户端（ASPx)只需知道Method_BLL()方法。

假如某一天Method_BLL()方法内的if(MethodA_DAL(id) > 5 && 其他条件)判断条件变了，（现实中往往DAL和BLL时一个解决方案里单独的项目，也就是生成各自的DLL），你只需修改BLL代码。

和数据库机械地打交道的放在DAL，比如CRUD操作，根据ID返回指定行等等（没一点智能的基础操作:－））。

然后在BLL层关心所谓商业逻辑，比如像只有工作5年以上的员工才给加薪10%等等。某个具体员工是否五年以上到DAL查，加薪也通过DAL。但BLL里你确实只关心程序要解决的具体问题。就想想假如DAL由公司另一个人早就写好了的情况吧，你可以完全不操心怎么访问数据库的问题。

现在的一个趋势是表现层就做你该做的事。像aspx页面,wpf/sl的前端xaml，你的后台代码除了和表现层相关的代码之外最好什么都没有，也就是说“有工作5年以上的员工才给加薪10%”，这种活儿你不要参与。。。
------解决方案--------------------
将代码逻辑都放在WEB层 这是最快的开发方式

但是到了后期维护你就知道痛苦了

这就显示出三层的优势了
------解决方案--------------------
小李：1+2+....+100=?
很简单, 写个循环嘛
……
……
……
小白：1+2+....+99=?
很简单, 写个循环嘛
……
……
……
小明：1+2+....+98=?
到第三个人的时候，简单的东西就不简单了。再多的时候，你的代码就没有什么可维护性了。

而用了三层，乱七八糟的重复性功能，你调用一下BLL,DAL 就好。
那你说， 只要DAL就好了， 不需要BLL啊。 

再举个例，妈妈买了茄子回来(DAL), 但是呢你要吃红烧的，你妹要吃清蒸的(UI)。
那怎么办呢？那就分几种做吧。
这就是中间层的一种好处。
比如说，网站上有的地方需要学生的信息---xml类型， 有的地方需要List类型， 有的地方需要json类型。
在DAL层， 你做成List就好了。而在BAL层， 你再由list分成xml,list,json三个方法。

当然，BLL的本意是业务逻辑，并不只是数据访问。
如果你不需要BLL，把全部的业务逻辑写在页面上，在业务庞大时，你的页面代码将臃肿不堪。到时你的代码将非常难于维护。——当然，此时的你，也许没有见过有人将一个页面代码写到几千行。而有分层的话，页面上几百行就够了。
------解决方案--------------------
等你做一个大型的项目，牵扯到很多的数据，页面你就知道把所有的代码写到页面上的痛苦了。。。

------解决方案--------------------
分层是为了以后的维护。。。
------解决方案--------------------
大项目才有感觉 小项目当然用不到了