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查询放入业务层

回答

相关问题