我们正在考虑将 MVC 4 用于大型应用程序。
我们的 DBA 担心“失去对数据库的控制”,并且不喜欢应用程序代码定义/更改数据库结构的想法。我能理解。他认为这对于单人团队或小型商店来说非常棒,但不明白它如何适合配备 DBA 员工的企业解决方案。他将在哪里适应这个过程?
我想 EF 在企业环境中被广泛使用,有没有什么好的文章可以更好地告诉我们如何使用 EF 与编码员编码和 DB 人员管理表的传统环境相比?
我们正在考虑将 MVC 4 用于大型应用程序。
我们的 DBA 担心“失去对数据库的控制”,并且不喜欢应用程序代码定义/更改数据库结构的想法。我能理解。他认为这对于单人团队或小型商店来说非常棒,但不明白它如何适合配备 DBA 员工的企业解决方案。他将在哪里适应这个过程?
我想 EF 在企业环境中被广泛使用,有没有什么好的文章可以更好地告诉我们如何使用 EF 与编码员编码和 DB 人员管理表的传统环境相比?
您似乎对 Entity Framework 是什么、它是如何使用以及如何使用存在误解。
实体框架被称为 ORM 或对象关系映射器。ORM 本身并没有任何东西可以从 DBA 手中夺走任何控制权。
确实,EF 可以生成表、数据模型、sql 等。但它不是必须的。其他 ORM 也不行。ORM 的核心是简单地获取一个结果集,并将其映射到对象集合。这也可以通过存储过程来完成。
大多数人喜欢做即席查询,EF 非常适合,但如果您的 DBA 要求所有查询都由他编写(或由他批准,并使用存储过程),那么它当然可以这样使用。
当前版本的 Entity Framework 确实只支持查询映射,但 EF 6,由于年底发布将添加对 Insets、Update 和 Deletes 的支持。您今天可以将这些作为查询进行,但它们不会映射到对象。
但老实说,您的 DBA 应该真正面对 DBA 变得越来越没必要的事实。他们将永远占有一席之地,但他们确实需要接受他们无法像曾经拥有的那样对查询执行进行铁腕控制。用户(以及开发人员)需要更多的动态查询,这意味着执行生成的 sql。
好吧,这个问题有点笼统,但如果我没记错的话,Microsoft® .NET:Architecting Applications for the Enterprise这本书有一个关于数据访问层和 ORM 的非常详细的章节/设置。