3層架構 - 是否可以將SQL查詢放入業務層

我的asp.net項目基於三層架構。3層架構 - 是否可以將SQL查詢放入業務層

（數據訪問層）DAL - （類庫）

private static string connString =""; 

    private static OracleConnection conn; 

    public static OracleConnection OpenConn() 
    { 
     if (conn==null) 
     { 
      conn = new OracleConnection(connString); 
     } 
     if (conn.State != ConnectionState.Open) 
     { 
      conn.Open(); 
     } 

     return conn; 
    } 

    public static DataTable Select(string query) 
    { 
     DataTable dt = new DataTable(); 
     OracleDataAdapter da = new OracleDataAdapter(query, OpenConn()); 
     da.Fill(dt); 
     return dt; 
    } 

    public static void Execute(string query) 
    { 
     OracleCommand cmd = new OracleCommand(query, OpenConn()); 
     cmd.ExecuteNonQuery(); 
    }

我已經把我所有的問題在（業務邏輯層）BLL類（所有BLL類是單獨的類庫項目）

如EmployeeBLL

public static class EmployeeBLL 
{ 
    public static DataTable Employees() 
    { 
     DataTable dt = new DataTable(); 
     string q = string.Format("select * from employees"); 
     dt = OraDAL.Select(q); 
     return dt; 
    } 

    public static DataTable AddEmployee(string name) 
    { 
     DataTable dt = new DataTable(); 
     string q = string.Format("INSERT INTO employees (ename) VALUES('{0}')", name); 
     dt = OraDAL.Select(q); 
     return dt; 
    } 
}

我曾經見過的SQL查詢在BLL構造，這就是爲什麼我開發的項目keepi上三層架構的一些博客文章在BLL ng sql查詢，但現在我覺得我應該將它們移動到DAL。

所以我的問題是

難道好保持SQL查詢中BLL或者我應該將它們移到DAL？
可以使用數據表來移動圖層之間的數據，還是我應該使用DTO？

來源

2013-03-12 ZedBee

您可能會發現http://stackoverflow.com/a/15267352/187752有用。 – Kimi 2013-03-12 14:06:46

Is it okay to keep sql queries in BLL or I should move them to DAL?

沒事的，但我不認爲這是正確的事情。把它們放在你所屬的DAL中。

Is it okay to use datatables for moving data between layers or I should use DTO's instead?

我更喜歡使用DTO，我認爲這是要走的路，但可以使用DataTables。

來源

2013-03-12 12:27:39

@BigDaddy，你能爲你的答案提供一些理由嗎？我現在半途同意你的觀點，但是我可能完全同意，如果我明白爲什麼你覺得把SQL放在你的BLL中並且「可以接受」來傳遞DataTables是「好的」。 – 2013-03-12 13:03:12

@JohnMGant ...通過「好吧」我的意思是你可以做到這一點，但在我看來，它並沒有做到這一點。數據訪問邏輯屬於DAL或類似，不會污染其他層。就DTO和DataTable而言，我至少5年沒有使用DataTable來傳輸數據，但這並不意味着這樣做是錯誤的 - 對我而言，這使得它「可以接受」。我總是爲此使用DTO /實體。 – 2013-03-12 13:45:43

@BigDaddy，好吧，這很有道理。我讀「好吧」爲「確定，繼續」，並沒有在這句話中進一步闡述。至於DataTables，我不會推薦用於新設計。在我看來，更好地傳遞明確定義的業務對象的IEnumerables。這爲您提供了一套更好的數據處理方法，並將安全性作爲獎勵。 – 2013-03-12 15:20:57

將應用程序分層的美妙之處在於，如果您需要更改數據存儲庫，那麼您可以儘量減少痛苦;再加上你可以測試你的對象與嘲笑隔離等

如果你開始硬連線SQL查詢等業務對象 - 然後移動，比如說，SQL，而不是甲骨文可能意味着重構業務對象層以及數據層。

我個人認爲業務對象不應該看到數據表。更好的方法是擁有數據層和業務層引用的共享對象（或接口）。

來源

2013-03-12 12:28:02 NDJ

你應該檢查像NHibernate或實體框架4 +的ORM，但是因爲你正在使用Oracle NHibernate是更好的IMO。

ORM將基本上代表您的DAL，它將負責爲您創建SELECT，INSERT，UPDATE和DELETE語句，並以您當前映射到的數據庫的方言進行操作。

它將允許您在您的域模型上而不是在表上執行查詢。這就是你想要做的。它會將數據庫抽象出來，以便將來可以創建新的映射並將您的域對象映射到MySQL。或者對某些內存數據庫執行附加映射，以便運行快速集成測試。

學習NHibernate（或其他ORM）是一項投資，但IMO如果將來將與.NET和RDBMS一起工作，那麼值得你花時間。

來源

2013-03-12 12:35:39

絕對正確..我嘗試使用EF，但後來遇到了與oracle的一些問題。 – ZedBee 2013-03-12 12:43:13

3層架構 - 是否可以將SQL查詢放入業務層

回答

相關問題