【问题标题】:architecture ASP.NET MVC 5架构 ASP.NET MVC 5
【发布时间】:2013-12-27 19:33:27
【问题描述】:

我正在使用 ASP.NET MV5 和实体框架进行项目。我以最好的方式得到了一些与架构应用程序相关的问题。我有现有数据库,所以我将使用代码优先现有数据库方法(代码或设计?)可能我也会使用存储过程

现在,如果我使用代码优先现有数据库设计方法,我应该为每个业务关注点或一个设计(ADO.NET 实体模型)设置单独的模型。我刚刚意识到我的一些模型将在不同的业务功能之间共享,例如 ASP.NET 身份表“角色”正在使用我的仪表板控制器,它在哪里看到,谁可以使用什么功能!

我可以先混合现有数据库的代码--> 设计和代码方法吗?

如果我使用代码优先现有的数据库设计方法,我可以去修改模型吗?

我应该有一个 DbContext 来读取数据库还是单独的?为什么我要问在一个 DbContext 下运行的代码是否会带来所有数据!我真的需要那个吗?它会影响性能吗?安全性是否对每个业务问题都有多个 DbContext?

我知道这是非常开放的问题。我更感兴趣的是使用 ASP.NET 技术以最佳方式看到架构复杂应用程序中的其他专家方法。

非常感谢

【问题讨论】:

  • 为什么要增加一层额外的复杂性?在 EF 上下文之上添加您自己的数据层只是另一个抽象层,其中可能会引入错误和不一致。
  • 那么如果我使用代码优先现有数据库设计方法,那么您的建议是什么,那么我有一个用于整个应用程序的 ADO.NET 实体模型?
  • 嗯,这就是我个人会做的事情。除非你有很大的动机去增加一层额外的复杂性,否则我看不到它的价值。

标签: c# sql-server asp.net-mvc entity-framework architecture


【解决方案1】:

对于小型项目,直接使用实体对象可能没问题。但是,如果您想执行复杂的验证并应用业务规则,最好创建单独的业务对象。实体对象本质上只是数据对象。

您可以使用AutoMapper 等实用程序来简化实体和业务对象之间的转换,并消除错误和不一致,同时保持业务对象和实体对象之间的清晰分离。

从长远来看,这是一个更可持续的架构。

【讨论】:

    猜你喜欢
    • 2016-11-22
    • 2015-04-06
    • 2010-10-06
    • 2010-10-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2015-06-24
    • 2014-01-25
    相关资源
    最近更新 更多