日期:2014-05-20  浏览次数:21097 次

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,把全部的业务逻辑写在页面上,在业务庞大时,你的页面代码将臃肿不堪。到时你的代码将非常难于维护。——当然,此时的你,也许没有见过有人将一个页面代码写到几千行。而有分层的话,页面上几百行就够了。
------解决方案--------------------
等你做一个大型的项目,牵扯到很多的数据,页面你就知道把所有的代码写到页面上的痛苦了。。。

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