總是遍歷業務層到達數據層？

我已經在單獨的項目中設置了我的VS解決方案，包括：Presentation，Business，Entities和Data Access Layers。我在DAL中有這個靜態類AppSettings，我想在Globla.asax.cs中調用它的Load()方法Application_Start。它基本上從web.config加載我的應用程序設置。我的問題是：我應該做一個業務邏輯類來從我的表示層訪問它，或者我可以直接從我的表示層訪問我的AppSettings到DataAccess層（忽略業務層）。總是遍歷業務層到達數據層？

如果是這樣，這是否也適用於一切？我必須經常通過業務層到達數據層嗎？

public static class AppSettings 
{ 
    public static int ApplicationID { get; set; } 
    public static string ServiceEndpoint { get; set; } 
    public static string ServiceCode { get; set; } 
    public static string ConnectionString { get; set; } 

    public static void Load() 
    { 
     //Connection String 
     AppSettings.ConnectionString = System.Configuration.ConfigurationManager.ConnectionStrings["USpace"].ConnectionString; 

     //Applicatin Settings 
     AppSettings.ApplicationID = Convert.ToInt32(System.Configuration.ConfigurationManager.AppSettings["AppID"]); 
     AppSettings.ServiceEndpoint = (string)System.Configuration.ConfigurationManager.AppSettings["ServiceEndpoint"]; 
     AppSettings.ServiceCode = (string)System.Configuration.ConfigurationManager.AppSettings["ServiceCode"]; 
    } 
}

如果我必須經過業務邏輯層BLL的類將這個樣子？：

public static class BLLAppSettings 
{ 
    public static int ApplicationID 
    { 
     get 
     { 
      AppSettings.ApplicationID 
     } 
    } 
...

來源

2012-01-26 capdragon

如果你的重點是設計模式，然後通過各種手段，有樂趣的衝擊那些方形栓在小圓孔裏。

如果您將重點放在應用程序設計上，那麼您將重點放在對您的應用程序有意義的設計模式中，甚至針對應用程序的各個部分。

瞭解模式就是知識。不知何時，當沒有，使用它們是智慧......

這是一個人的oppinion，但我希望它可以幫助...

來源

2012-01-26 14:30:48 ShaneBlake

它確實有幫助謝謝（+1）你是否說我可能不需要訪問appSettings的業務類，只需直接調用DAL？ – capdragon

一個業務層可以提供一個地方來統一應用業務規則到您的數據。如果實體沒有業務規則，那麼爲什麼要使用業務層呢？額外的代碼層，只是提供了一個溫暖的模糊「我遵循模式」的感覺，對我來說，是一種浪費... – ShaneBlake

對我有意義。 – capdragon

我建議總是會通過商業邏輯層來訪問數據層，這樣業務邏輯層內置的所有安全措施都在發揮作用。您是否希望在沒有業務層的情況下使用數據層？

來源

2012-01-26 14:31:16 ERukes

好點...保障措施。我認爲這是重點。（+1） – capdragon

Ayende最近發表了幾篇文章反對這種做法（我的理解是這樣的）：

http://ayende.com/blog/153061/northwind-starter-kit-review-it-is-all-about-the-services

，我同意他的說法：你必須問你自己「這是什麼層的目的「如果你無法回答，那麼你不能刪除這一層，並保持你的軟件簡單。

因此，如果您在獲取數據時沒有業務操作，請直接處理數據層！

來源

2012-01-27 13:39:58

有趣的是，它認爲你加強了ShaneBlake的觀點。（+1） – capdragon

我絕對是一個保持簡單的倡導者，但我也是一個很大的支持者，在前面添加足夠的抽象以保持選項的開放性和代碼的靈活性。這絕對是一種平衡，但有點抽象可以走很長的路。 – dblood

@dblood：假設您現在想在插入產品時向某人發送電子郵件。所以你會有你的電子郵件發送代碼在你的服務。你很高興，你認爲這很容易。但是如果在某些情況下你不想發送這封郵件呢？當你有這種審訊時，這意味着你打破了SRP原則：你改變了你的課堂責任！所以這是一個可能導致很多痛苦的層面（例如，您的客戶在您的修補程序的第一天晚上會收到10 000次，因爲您每天晚上都會忘記使用服務層的這批次）。 –

如果數據是在應用程序的配置文件（Web.config）你並不需要「經過」任何東西，除了System.ConfigurationManager.AppSettings

來源

2012-01-27 13:49:33 Jason

你是對的，因爲[web.config已被緩存]（http://weblogs.asp.net/stevewellens/archive/2011/01/15/web-config-is-cached.aspx）。但是，從所有圖層訪問Sys.Config.App可以嗎？ – capdragon

這種方法的不足之處在於，您可以連接到web.config。有時候可以，但是如果你想在另一個只讀取數據庫設置的應用程序中使用BLL，該怎麼辦？你必須重構。通過在前面添加一點抽象，當您不得不從ConfigurationManager重構時，您的工作將更容易。 – dblood

我認爲這是不必要的額外工作。當需要出現時，重構它會很容易。 – Jason

你應該保持它的簡單而合理的範圍內開始了。設計應用程序時，軟件工程的一般原則應該是您的指導。在這種情況下，我的直接想法是，通過擁有一個全局AppSettings類，您將將業務和數據訪問層耦合到該類。這看起來似乎是合理的，但當你有50個不同的設置並且只有20個適用於數據訪問層時呢？如果在路上，您的業務層必須從不同於DAL的源加載設置？最重要的是，在你現在的設計中，你將這兩個層連接到全局單例。這通常不是一個好主意。

即使在較小的應用程序中，我也會主張爲每個圖層定義不同的設置對象。在我的設計中，它與您的BLLAppSettings類似。它將封裝設置的來源，在這種情況下是您的全局AppSettings類。但是，在我的設計不同的地方，BLLAppSettings將是BLL層中定義的一個接口的具體實例，必須通過構造器，工廠或依賴注入將其提供給BLL層。在我推薦的設計中，類似的類DALAppSettings是必要的。

以這種方式，您的BLL和DAL不會耦合到表示層中定義的全局AppSettings。 BLLAppSettings和DALAppSettings的實現細節可以在必要時獨立變化，但暫時可以在內部與您的全局AppSettings類保持關聯。

來源

2012-01-27 13:59:41 dblood

有趣，從來沒有想過（不同層次的不同設置類）。好點（+1） – capdragon

總是遍歷業務層到達數據層？

回答

相關問題