现在以某种方式直接查询表格好吗？

Question

过去，任何值得他盐的数据库管理员都会告诉你永远不要直接查询表。实际上，他们会通过将所有表格放在一个模式中来阻止它。切断对该架构的直接访问...从而迫使您从视图中查询或CRUD＆amp;此外，从安全角度来看，使用这样的安全层保护数据是有意义的。

现在进入实体框架......

我们现在在工作的地方使用Entity Framework。 IQueryable是国王！一切都回到了DBO架构中。并且，人们直接进入左右表格，因为存储库模式和在线示例似乎鼓励这种做法。

• 实体框架是否会做一些让这种做法现在正常的事情？
• 如果是这样，它会做什么？
• 为什么现在好吗？

帮助我理解。

Answer 1

• 实体框架是否会做一些事情 现在练习好吗？

EF并没有真正改变动态。它是数据访问和快速开发的便利，而不是获取数据的更好方法。

• 如果是这样，它会做什么？

没有。我认为，它至少可以避免构造SELECT *类型的查询。

• 为什么现在好吗？

这仍然是一个观点和文化的问题。一般来说，＆＃34;严格＆＃34; DBA将要求您仅在CRUD的表顶部分层显示分层的外露对象。如果应用程序使用公开自定义对象而不是使用ORM或手动编码直接查询，则更容易调整此类查询并保持对性能的控制。

IMO，ORM非常适合快速原型设计和基本功能，但任何具有更复杂逻辑或实质性能的东西都应该转移到自定义构建的对象上。

这些线的位置/时间会根据任何数量而有很大差异，包括：

1. 数据库的大小/负载
2. 数据库专业人员与应用程序的可用性 开发人员
3. 公司成熟度

Answer 2

有不同类型的实体框架（代码优先，数据库优先，模型优先）。看来Code First存在问题，它根据您的类创建数据库，并限制您在数据库方面可以做的事情。

然而，使用EF Database First，您仍然可以完成之前所做的一切。您可以限制对表的访问，并为CRUD操作公开存储过程/视图。您仍然可以从EF中受益，因为从您的视图生成的强类型类以及从您的存储过程生成的强类型方法。

现在每个人都可以开心 - 你可以切断对架构的访问和 IQueryable仍然是王