Question

目前我基本上添加了对Microsoft.Practices.EnterpriseLibrary.Common .Data .ObjectBuilder的引用

我发现自己正在创建像'Product'这样的持有类，然后有另一个类创建像Products：List

这样的列表

public class Products : List<Product>
{
    public Products()
    { }

    public void SelectAll()
    {
        Database db = DatabaseFactory.CreateDatabase();

            using (IDataReader r = db.ExecuteReader(cmd))
            {
                while (r.Read())
                {
                    this.Add(new Product(Convert.ToInt32(r["PRODUCT_ID"]),
                                        r["NAME"].ToString())
                                     ));
                }
            }

    }

}


Products p = new PRoducts()
p.SelectAll();

现在我的所有产品都很好。

这没关系，但我已经使用它几年了。我听说过LINQ和实体框架，但并没有真正采取与nHibernate一起使用的步骤，但并没有真正采取任何措施。仍然使用这种方法是错误的。

Answer 1

坚持你所知道的东西没有错，只要它有效。

但是，我会建议您了解您提到的ORM，并了解他们想要实现的目标。

你永远不应该做的是停止学习。看看新的框架和开发方法 - 如果不出意外，它会让你成为更好的程序员。

Answer 2

将EntLib DAAB用于数据访问层没有任何问题，特别是如果您只有几个类/表。

但是，使用ORM（例如Linq2SQL，EF 4和最新版本的NH）有一些显着的好处：

自动生成数据访问器和实体代码
延迟加载
支持LINQ表达式树 - 这样可以在没有任何SQL编码的情况下提供极大的查询灵活性（尽管需要注意的是对正在执行的SQL的可见性较低 - 这可能会影响性能）。

在大多数情况下，您可以使用上述ORM中的一个执行大约90％的DAL，并且对于精细级别的“控制”，您可以手动构建SPROC。在大多数情况下，您仍然可以将您的SPROC连接到ORM实体。

Answer 3

继续使用适合你的东西并不是错的。

企业库仍在积极开发中，可能会在相当长的一段时间内继续使用。我们广泛使用它，并将在可预见的未来继续这样做。

我建议您及时了解实体框架等各种内容，除了了解各种选项可以为您做什么之外没有其他原因。

Answer 4

以这种方式进行数据访问绝对没错。它使您可以最大程度地控制执行的语句以及数据如何在代码中流动。

像EF或Hibernate这样的OR-Mappers在某些情况下会给你更多的舒适感，但它们也有它们的缺点。

Answer 5

这不是“错误的”，本身，但使用此方法与对象关系映射器（ORM）（如EF或NH）是：

一种非常强制性的风格（与陈述性相反 - 你关注“如何”而不是“什么”）
更难阅读
更难以维护，因为它更难以阅读，因为数据库中的更改可能会导致整个数据访问代码库中的一系列更改
更难测试

我不建议将整个工作代码库重新用于ORM，但值得学习和理解。我建议先看一下LINQ-to-SQL，在一个示例项目中，当然，因为这是一种轻量级的“小伙子”ORM，但开始使用起来非常快。从那里，您可以继续前往EF和/或NH。实体框架在感觉和工具方面更类似于L2S，而NHibernate具有更陡峭的学习曲线，但更强大/更灵活。

同样，使用企业库和数据加载器没有任何问题，但使用ORM确实有优势并且通常可以节省时间，最明显的是数据访问的“脏工作”得到了解决，并且几乎可以保证与手动数据访问相比，缺陷更少，效率更高。

也就是说，对于使用数据库有限的非常小的项目，所有添加的抽象可能都没有必要，直接的ADO .NET将更快更容易。

C＃替代或更多当前数据访问然后企业库

5 个答案: