【问题标题】:Using an existing entity framework class library with MVC WebAPI将现有的实体框架类库与 MVC WebAPI 一起使用
【发布时间】:2013-04-04 14:47:31
【问题描述】:

我有一个包含我所有实体框架代码的类库。

在一个标准的 ASP.NET 项目中,我可以引用这个 DLL 并开始使用这些类并与我的数据库进行交互。

但是,我现在开始使用新的ASP.NET MVC Web API 构建一个新的 Web API。我希望能够在这个新 API 中使用这个现有的库,但我不确定如何连接它。这是可能的吗?还是我应该为这个项目重新生成实体集?

我在 MVC 方面的经验有限,并且只用它构建了一个小型产品组合,并且该站点具有所有新模型和实体等。

我尝试添加一个控制器并从我的实体库和数据上下文类中选择模型类,但收到“不支持的上下文类型”消息。

如果有帮助,我可以将实体库的代码作为一个单独的项目添加到我的解决方案中,而不仅仅是 DLL,尽管我希望对此进行最小的更改,因为其他项目使用相同的框架。

更新

我知道我可以使用 DbContext 生成器为 EF 实体生成所有 dbContext 类,但我想知道是否还有其他方法,因此我不必将 EF 文件也直接添加到此项目中。

【问题讨论】:

  • 上下文类的基本类型是什么?
  • 我使用设计器 (*.edmx) 构建了这一切 - 假设那将是 ObjectContext 类?

标签: asp.net-mvc entity-framework asp.net-web-api


【解决方案1】:

这是我们为每个系统确定的配方,让我们处于有利地位。

项目:

用于部署目的的 SQL Server 项目。 EDM 项目用于保存 EF 模型和数据上下文,无需生成代码。 带有 T4 模板的实体/POCO 项目可从 EDM 自动生成类。

WCF 服务解决方案包含上述所有三个项目以及 WCF 服务项目本身,可以访问数据上下文并以受控方式向任何 UI 层公开对象。

UI 还包含实体/POCO 项目和 UI 项目本身中对服务的引用,服务引用在该实体项目程序集中重用类型。

好处:

  1. 几乎没有重复。
  2. 快速的可维护性和可持续性。
  3. 关注点分离。
  4. 通过 Net Tcp 服务实现可扩展性。

总而言之,我不会使用 DLL 引用,我会使用 Entity/Poco 项目作为中介,包含在应用程序交付的两端。

希望对你有所帮助。

【讨论】:

    猜你喜欢
    • 2015-01-10
    • 1970-01-01
    • 1970-01-01
    • 2011-06-20
    • 1970-01-01
    • 2017-06-25
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多