3层架构——将sql查询放在业务层是否可以答案

【问题标题】：3 Layer Architecture - Is it fine to put sql queries in Business layer3层架构——将sql查询放在业务层是否可以
【发布时间】：2013-02-27 23:00:33
【问题描述】：

我的 asp.net 项目基于三层架构。

（数据访问层）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 中构建的，这就是为什么我开发了将 sql 查询保留在 BLL 中的项目，但现在我觉得我应该将它们移至 DAL。

所以我的问题是

是否可以将 sql 查询保留在 BLL 中，或者我应该将它们移至 DAL？
是否可以使用数据表在层之间移动数据，或者我应该使用 DTO 来代替？

【问题讨论】：

您可能会发现stackoverflow.com/a/15267352/187752 很有用。

标签： c# asp.net architecture

【解决方案1】：

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 是可以接受的。

【讨论】：

@BigDaddy，你能为你的回答提供一些理由吗？我现在同意你的一半，但如果我理解你为什么认为将 SQL 放在你的 BLL 中“可以”并且“可以接受”传递 DataTables，我可能会完全同意。
@JohnMGant ...“好吧”我的意思是你可以做到，但在我看来它并不正确。数据访问逻辑属于 DAL 或类似的，不会污染其他层。至于 DTO 与 DataTable，我至少有 5 年没有使用 DataTable 来传输数据了，但这并不意味着这样做是错误的——对我来说，这使它“可以接受”。为此，我总是使用 DTO/实体。
@BigDaddy，好的，这是有道理的。我将“好的”读作“当然，继续”，并且在那句话中没有进一步说明。就 DataTables 而言，我不建议将其用于新设计。在我看来，传递定义良好的业务对象的 IEnumerables 会好得多。这为您提供了一组更好的数据处理方法，并将类型安全作为奖励。

【解决方案2】：

您应该检查像 NHibernate 或 Entity Framework 4+ 这样的 ORM，但是当您使用 Oracle NHibernate 时，IMO 更好。

ORM 基本上代表您的 DAL，它将负责以您当前映射到的数据库的方言为您创建 SELECT、INSERT、UPDATE 和 DELETE 语句。

它将允许您对域模型而不是表进行查询。这就是你想要做的。它将抽象您的数据库，以便您将来可以进行新的映射并将您的域对象映射到 MySQL。或者在一些内存数据库上做额外的映射，以便您运行快速集成测试。

学习 NHibernate（或其他 ORM）是一项投资，但如果您将来要使用 .NET 和 RDBMS，IMO 值得您花时间。

【讨论】：

绝对正确.. 我尝试使用 EF，但后来遇到了 oracle 的一些问题。

【解决方案3】：

将应用程序分层的好处在于，如果您需要更改数据存储库，您可以轻松地做到这一点；另外，您可以使用模拟等单独测试您的对象。

如果您开始将 sql 查询等硬连接到业务对象中 - 比如说，迁移到 SQL 而不是 oracle 可能意味着重构业务层和数据层内的对象。

我个人认为业务对象不应该看到数据表。更好的方法是拥有数据层和业务层都引用的共享对象（或接口）。

【讨论】：