引言
本文提到的分層只是軟件架構(gòu)上的分層。文中的傳統(tǒng)分層指的是傳統(tǒng)的三層結(jié)構(gòu)：UI（界面表現(xiàn)層）,BLL（業(yè)務(wù)邏輯層）,DAL（數(shù)據(jù)訪問層）。文中提出的觀點也都是個人的一點認識，與任何組織沒有關(guān)系，如有異議，還請各位踴躍拍磚。
當(dāng)然了，出現(xiàn)的這些問題，也可能只是我個人的問題，不代表每個人都存在。無則加勉，有則改正吧。如果是個人的問題，那就當(dāng)是個人總結(jié)吧，大家看看就算了。
這里說到的傳統(tǒng)分層，也有可能是我對于分層的錯誤理解造成的，但是我看見的不只是我的項目是這么的結(jié)構(gòu)，很多的項目也都是這樣的結(jié)構(gòu)。里面的代碼， 都和我理解的一樣，至少可以說明，還是有一部分人犯了和我一樣的錯誤。
傳統(tǒng)分層
傳統(tǒng)分層最大的問題就在于割裂了上層與下層之間的聯(lián)系，把他們之間的關(guān)系變成了簡單的接口調(diào)用，變成了完全的接口形式主義。同時，忽略了下層是為上層提供服務(wù)的，不是單獨存在的，下層提供的服務(wù)應(yīng)該受到上層的規(guī)約。當(dāng)然，也不是說不可以提供更多的服務(wù)，但是至少應(yīng)該提供上層需要的，然后再考慮提供一些“邊角料”。
我們先看一個傳統(tǒng)分層的解決方案結(jié)構(gòu)。
相互之間的引用關(guān)系是：UI引用BLL、Entity、Common；BLL引用IDAL、Entity、Common；IDAL引用Entity；DAL引用IDAL、Entity、Common。
顯示行號 復(fù)制代碼 ？ UI Code
private void button1_Click(object sender, EventArgs e)
{
_02_BLL.OrderBll orderBll = Common.ServiceLocator.LoadService<_02_BLL.OrderBll>();
orderBll.SubmitOrder(new _05_Entity.OrderEntity()
{
OrderSeqNo = "123",
OrderAmount = 1000
});
}
顯示行號 復(fù)制代碼 ？ BLL Code
public class OrderBll
{
IOrderDal _orderDal;
public OrderBll()
{
_orderDal = Common.ServiceLocator.LoadService<_03_IDAL.IOrderDal>();
}
public bool SubmitOrder(OrderEntity order)
{
return _orderDal.Add(order);
}
}
顯示行號 復(fù)制代碼 ？ IDAL Code
public interface IOrderDal
{
bool Add(OrderEntity order);
}
顯示行號 復(fù)制代碼 ？ DAL Code
public class OrderDal:_03_IDAL.IOrderDal
{
public bool Add(_05_Entity.OrderEntity order)
{
IDbConnection conn = new SqlConnection();
conn.Open();
IDbCommand comm = conn.CreateCommand();
IDbDataParameter param = comm.CreateParameter();
param.Direction = ParameterDirection.Input;
param.DbType = DbType.String;
param.ParameterName = "OrderSeqNo";
if (comm.ExecuteNonQuery() > 0)
return true;
else
return false;
}
}
顯示行號 復(fù)制代碼 ？ Unity Container Locator
using System.Configuration;
using System.Globalization;
using Microsoft.Practices.Unity;
using Microsoft.Practices.Unity.Configuration;
using Microsoft.Practices.Unity.InterceptionExtension;
using System.Web;
using System;
namespace Common
{
public static class ServiceLocator
{
// private static readonly InterfaceInterceptor injector = new InterfaceInterceptor ();
private static readonly TransparentProxyInterceptor injector = new TransparentProxyInterceptor();
public static IUnityContainer Container
{
get;
private set;
}
static ServiceLocator()
{
Container = new UnityContainer();
UnityConfigurationSection unitySection = ConfigurationManager.GetSection("unity") as UnityConfigurationSection;
if (unitySection == null)
{
throw new ConfigurationErrorsException(string.Format(CultureInfo.CurrentCulture, "missing unity configuration section"));
}
Container.AddNewExtension<Interception>();
unitySection.Configure(Container, "Container");
}
/// <summary>
/// 沒?有D為a映3射?指?定¨別e名?
/// name屬?性?沒?有D賦3值μ
/// </summary>
/// <typeparam name="T"></typeparam>
/// <returns></returns>
public static T LoadService<T>()
{
Container.Configure<Interception>().SetDefaultInterceptorFor<T>(injector);
return Container.Resolve<T>();
}
/// <summary>
/// 為a映3射?指?定¨別e名?
/// name屬?性?賦3值μ
/// </summary>
/// <typeparam name="T"></typeparam>
/// <param name="serviceName"></param>
/// <returns></returns>
public static T LoadService<T>(string serviceName)
{
Container.Configure<Interception>().SetDefaultInterceptorFor<T>(injector);
return Container.Resolve<T>(serviceName);
}
}
}
上層在調(diào)用下層的時候，不是調(diào)用自己需要的，而是從下層提供的服務(wù)中篩選一些可以用的，湊合用一下。如果發(fā)現(xiàn)沒有自己可以用的，就在IDAL文件中添加一個，然后在DAL文件中實現(xiàn)以下，這下好了，BLL可以用了。這樣也會造成在開發(fā)DAL層的時候，沒有充分考慮BLL的需要，自己盲目實現(xiàn)一些，然后BLL用的時候，才發(fā)現(xiàn)很多還要重新寫。造成大量的浪費，代碼、人力、時間、精力都浪費一部分了。也會影響到開發(fā)的進度。
新式分層,抑或叫做DDD分層
說是新式分層，其實也是我隨便叫的。就是這段時間看了博客園的一些DDD文章，還有就是codeplex上的兩個項目NLayerApp和SmartCA的源碼?？戳诉@些之后，有的一點理解。不管是神似還是形似吧，反正覺得比以前傳統(tǒng)分層有一點道理，就分享出來了，也掙點人氣，騙點點擊量，哈哈。
先來一張圖吧。
DDD中的分層主要是四層：Presentation（表現(xiàn)層），Application（應(yīng)用層），Domain（領(lǐng)域?qū)樱?，Infrastructure（基礎(chǔ)層）。
Presentation相當(dāng)于以前的UI層。Application是一個任務(wù)的調(diào)度層，沒有實際的業(yè)務(wù)邏輯，也不推薦放入業(yè)務(wù)邏輯，實際中可以用Wcf來代替，或者使用普通的類庫就可以。其實就是根據(jù)UI的業(yè)務(wù)調(diào)用，然后映射到具體的領(lǐng)域?qū)ο笊砩先?。也可以通過Application來暴露粗粒度的業(yè)務(wù)處理，因為領(lǐng)域?qū)拥臉I(yè)務(wù)處理是細粒度的。沒有了以前的DAL，把它的部分放入了Infrastructure層。
以前的IDAL被放入了Domain，在圖上，是Domain.Core項目，這個項目會被Infrastructure引用。因為Domain.Core中的IDAL相當(dāng)于是領(lǐng)域?qū)ο髮τ诔志没岢龅囊?，也就是說必須要實現(xiàn)這些功能，這些都是領(lǐng)域?qū)ο笮枰?。具體的如何實現(xiàn)，具體如何持久化，是持久化到關(guān)系數(shù)據(jù)庫還是文件系統(tǒng)，還是內(nèi)存數(shù)據(jù)庫，都由具體的實現(xiàn)來定義。也就是圖中的Infrastructure.Data.Core和Infrastructure.Data.MainModule項目。這兩個項目中的實現(xiàn)，實現(xiàn)的都是領(lǐng)域?qū)ο蟪志没枰?，不會實現(xiàn)一大丟不必要的方法。不知道這算不算是改進呢？
結(jié)論
傳統(tǒng)分層，或者說是我理解的傳統(tǒng)分層，存在的問題就是割裂層之間的聯(lián)系，形式化了層之間的聯(lián)系。沒有表達出上層對于下層的需要，下層是為上層服務(wù)的，這些聯(lián)系。DDD的分層可以解決這個問題，會提高開發(fā)的效率，少走一些彎路。
不知道大家是如何認識的呢？？？？？？？？期待大家的回復(fù)，拍磚。
