Question

我刚刚开始研究现有（启动）项目，目的是在结构和性能上重新组织它。我通常使用EF作为框架，但我也熟悉Linq-to-sql和ADO。我所看到的是，现在Web应用程序正在使用实际的数据库表＆amp;视图作为代码中的对象，例如，您有表＆＃39; foo＆＃39;他们会继续使用它作为对象，而不是使用类来传递应用程序内部的数据，最后将其插入到数据库/表中。因为我从来没有看过这个并且没有意识到它，我想知道，这是一个好的＆＃34;实践，我的意思是微软确实可以这样做，所以最重要的是真实的＆＃34;目的，有优点/缺点吗？

谢谢大家的回复！亲切的问候

Answer 1

我之前看到过在Java和C＃中用作对象的存储库。我怀疑这就是你在这里谈论的内容。如果是这样，就会有很大的权衡。与mot工具一样，你如何使用它比使用它更重要，因此理解权衡更重要的是使用一揽子使用规则。

通常使用存储库，我们有一个负责存储和获取数据的对象。这可以像数据库表一样，但实际上是一个抽象，位于数据库和应用程序之间。在此持久化对象，并从中请求对象。存储库不了解对象的内部，只知道如何存储或获取它们。例如，它是Spring中的常见模式。

存储库与数据访问对象非常相似（实际上有些人认为它们是相同的，而其他人认为它们不是）。

优点是你有这种抽象，所以如果你想将对象存储在其他地方（比如，你想将它们写入Kafka而不是将它们写入数据库），你就有了一个可以做到这一点的存储库。因此，存储库不必告诉您它是如何获取或持久化数据的。它只需要实现您决定这样做的API。

这里的一个主要优点是您将业务逻辑与持久性逻辑分开（意味着您可以更改任何一个而不必担心另一个）。缺点是它们仍然是紧密耦合的，所以抽象并不像你想象的那么多，而且它的成本比你想象的要复杂得多。

我确信有代码生成器可以对SQL Server中的表执行此操作。但是，在您这样做的瞬间，您或多或少地将自己与代码生成器的API决策联系起来，这些决定部分地破坏了首先在那里进行抽象的目的。

Answer 2

所以既然你喜欢我的评论，我会扩展。假设我有桌子

Foo
FooId int 
Desc varchar(32)

Bar
BarId int
Desc varchar(32)

现在让我假装我实际上有更多，并说50个表。我不想手工创造所有这些，因为它会有点疯狂。回到ADO.NET的那一天，您将创建DataTables并可能手工制作格式良好的对象。使用Linq To SQL，他们制作了一个文档来处理大部分建模，但它几乎与数据库的外观完全相同。但随着实体框架MS向前迈进了一步。现在您有了数据库层，中间层和对象层。可以说，您甚至可以操纵和创建超出“上下文”所需内容的对象。

但除此之外，我要说我创建了一个Entity Framework 6.1.3模型，然后选择我的数据库并首先选择Database。当我添加对象时，我得到一个模型表示，它们存储在上下文中。就EF而言，这些对象就是表格。你只需做类似

的事情

using(var context = new DBContext())
{
    var newFoo = new Foo { Id = 1, Desc = "A" };
    context.Foo.Add(newFood);
    context.SaveChanges();
}

我刚刚添加并保存了一个新的Foo对象，我不需要创建任何POCO对象的代码。 EF通过选择模型对象并右键单击并选择“运行自定义工具”来运行自定义工具时为我做了这些。基本上这只是运行数据来为您生成POCO和设置。或者代码在T4中编写代码。您可以更新T4以更改设置，但我不建议过于疯狂。

你已经失败的方法更好。只需将代码包装在新方法中，您就拥有了一个存储库。存储库优于内联EF上下文的优点是您可以根据需要混合技术或更改它们。我唯一要说的就是将你使用的对象保留为EF或其他技术生成的对象。或者你可能有一些业务逻辑具有自动调用的属性，你不希望它们污染你的EF，但它们在回购模式中很好。存储库模式IMHO应该只是您的CRUD操作的中介，它位于检索技术和调用部分之间。

使用数据库表作为对象？

2 个答案: