引言

本文提到的分層只是軟件架構上的分層。文中的傳統分層指的是傳統的三層結構：UI（界面表現層）,BLL（業務邏輯層）,DAL（數據訪問層）。文中提出的觀點也都是個人的一點認識，與任何組織沒有關系，如有異議，還請各位踴躍拍磚。

當然了，出現的這些問題，也可能只是我個人的問題，不代表每個人都存在。無則加勉，有則改正吧。如果是個人的問題，那就當是個人總結吧，大家看看就算了。

這里說到的傳統分層，也有可能是我對于分層的錯誤理解造成的，但是我看見的不只是我的項目是這么的結構，很多的項目也都是這樣的結構。里面的代碼， 都和我理解的一樣，至少可以說明，還是有一部分人犯了和我一樣的錯誤。

?

傳統分層

?

傳統分層最大的問題就在于割裂了上層與下層之間的聯系，把他們之間的關系變成了簡單的接口調用，變成了完全的接口形式主義。同時，忽略了下層是為上層提供服務的，不是單獨存在的，下層提供的服務應該受到上層的規約。當然，也不是說不可以提供更多的服務，但是至少應該提供上層需要的，然后再考慮提供一些“邊角料”。

我們先看一個傳統分層的解決方案結構。

相互之間的引用關系是：UI引用BLL、Entity、Common；BLL引用IDAL、Entity、Common；IDAL引用Entity；DAL引用IDAL、Entity、Common。

顯示行號 復制代碼 ？ 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

});

}

顯示行號 復制代碼 ？ 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);

}

}

?

顯示行號 復制代碼 ？ IDAL Code

public interface IOrderDal

{

bool Add(OrderEntity order);

}

?

顯示行號 復制代碼 ？ 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;

}

}

顯示行號 復制代碼 ？ 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);

}

}

}

?

上層在調用下層的時候，不是調用自己需要的，而是從下層提供的服務中篩選一些可以用的，湊合用一下。如果發現沒有自己可以用的，就在IDAL文件中添加一個，然后在DAL文件中實現以下，這下好了，BLL可以用了。這樣也會造成在開發DAL層的時候，沒有充分考慮BLL的需要，自己盲目實現一些，然后BLL用的時候，才發現很多還要重新寫。造成大量的浪費，代碼、人力、時間、精力都浪費一部分了。也會影響到開發的進度。

?

新式分層,抑或叫做DDD分層

?

說是新式分層，其實也是我隨便叫的。就是這段時間看了博客園的一些DDD文章，還有就是codeplex上的兩個項目NLayerApp和SmartCA的源碼。看了這些之后，有的一點理解。不管是神似還是形似吧，反正覺得比以前傳統分層有一點道理，就分享出來了，也掙點人氣，騙點點擊量，哈哈。

先來一張圖吧。

DDD中的分層主要是四層：Presentation（表現層），Application（應用層），Domain（領域層），Infrastructure（基礎層）。

Presentation相當于以前的UI層。Application是一個任務的調度層，沒有實際的業務邏輯，也不推薦放入業務邏輯，實際中可以用Wcf來代替，或者使用普通的類庫就可以。其實就是根據UI的業務調用，然后映射到具體的領域對象身上去。也可以通過Application來暴露粗粒度的業務處理，因為領域層的業務處理是細粒度的。沒有了以前的DAL，把它的部分放入了Infrastructure層。

以前的IDAL被放入了Domain，在圖上，是Domain.Core項目，這個項目會被Infrastructure引用。因為Domain.Core中的IDAL相當于是領域對象對于持久化提出的要求，也就是說必須要實現這些功能，這些都是領域對象需要的。具體的如何實現，具體如何持久化，是持久化到關系數據庫還是文件系統，還是內存數據庫，都由具體的實現來定義。也就是圖中的Infrastructure.Data.Core和Infrastructure.Data.MainModule項目。這兩個項目中的實現，實現的都是領域對象持久化所需要的，不會實現一大丟不必要的方法。不知道這算不算是改進呢？

?

結論

傳統分層，或者說是我理解的傳統分層，存在的問題就是割裂層之間的聯系，形式化了層之間的聯系。沒有表達出上層對于下層的需要，下層是為上層服務的，這些聯系。DDD的分層可以解決這個問題，會提高開發的效率，少走一些彎路。

不知道大家是如何認識的呢？？？？？？？？期待大家的回復，拍磚。

轉載于:https://www.cnblogs.com/virusswb/archive/2011/01/10/1931964.html

總結

以上是生活随笔為你收集整理的小议传统分层与新式分层，抑或与DDD分层的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。