C# 3层体系结构-可以将sql查询放在业务层中吗

我的asp.net项目基于三层体系结构

（数据访问层）DAL-（类库）

我已经将所有查询放在（业务逻辑层）BLL类中（所有BLL类都在单独的类库项目中）

e、 g雇员

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中

使用datatables在层之间移动数据可以吗？还是我应该使用DTO 没关系，但我觉得这样做不对。把它们放在属于它们的地方

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

---

我更喜欢使用DTO，我认为这是一种方式，但使用DataTables是可以接受的。

将应用程序分为多个层的好处在于，如果您需要更改数据存储库，您可以用最少的痛苦来完成；此外，您还可以使用mock等单独测试对象

如果您开始将sql查询等硬连接到业务对象中，那么移动到sql而不是oracle可能意味着重构业务层和数据层中的对象

---

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

您应该检查诸如NHibernate或Entity Framework 4+之类的ORM，但在您使用Oracle时，NHibernate比IMO更好

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

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

---

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

绝对正确。。我尝试过使用EF，但后来在oracle方面遇到了一些问题。@Bigdady，你能为你的答案提供一些理由吗？我现在有点同意你的看法，但如果我理解你为什么认为在BLL中使用SQL是“可以”的，在传递数据表时是“可以接受的”。@JohnMGant…我说的“好”是指你可以做到，但在我看来这并不正确。数据访问逻辑属于DAL或类似类型，不会污染其他层。至于DTO和DataTable，我至少有5年没有使用DataTable来传输数据，但这并不意味着这样做是错误的——对我来说，这让它“可以接受”。我总是使用DTO/实体来实现这个目的。@Bigdady，好的，这是有道理的。我把“好的”读作“当然，说吧”，在那句话里没说太多。至于DataTables，我不建议将其用于新设计。在我看来，传递定义良好的业务对象的IEnumerables要好得多。这为您提供了一套更好的处理数据的方法，并作为奖励键入safety。

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

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