在设计时更改EF数据库 [英] Change EF database at design time

问题描述

我对EF很新。我认为这是在线促销和个人追求独立，但我不认为这是真的。我找到的所有示例，您都必须从EF生成数据库或从数据库生成EF。 
令人失望的是，数据库无关，这对我来说意味着我的实体模型可以通过适当的映射应用于各种体系结构的各种数据库。我没有找到任何解释，教程，论坛主题或示例来支持
。事实上，到目前为止，最好的解决方案是数据库或EF的重新生成/迁移。这是非常低效的。

**背景**

我有一个待售产品，并希望将动态数据库连接作为优势。现在，我可以用我自己的对象，类和SQL以老式的方式完成所有这些，但它会更快更有效，如果我能通过这样做，我可以快速上市
3倍EF。所以，我希望我只是遗漏了一些东西。

请原谅我缺乏示例，因为我正在保护我的财产，这更像是一个设计主题。但是，我会说它涉及医疗保健所以论坛参与者可以理解可能涉及的数据的大小以及为什么迁移
绝不是一种选择。谢谢。

我非常感谢任何指导。

解决方案

看来你在这里混合了几件事......

您提到的数据库独立性是您能够抽象出底层数据库。因此，相同的代码可以针对SQL Server或Oracle运行（实际上，您可能必须建立最佳实践和测试，因为无论数据库如何，底层的
功能并不总是相同的。）

使用映射，您可以处理一些模式差异，例如，如果列名称不相同等等...在某些时候，如果模式不同，只是不能支持您的抽象模型，那么您将陷入困境。如果你对db模式有一些控制权，那么你不会只是为了好玩。通常，无论实际的基础数据库如何，您都将使用相同的模式。

不确定是否通过"动态"你的意思是让用户改变数据库并让EF自动处理这个变化吗？

简而言之，EF是将数据作为强类型对象公开给你的代码。我的理解是你的应用程序必须与你无法改变的第三方数据库模式一起工作，并且你希望能够使用EF将每个模式映射到你的应用程序使用的单个模型
？ / p>

I'm very new to EF. I perceived it's promotion both online and personal as being back end independent, but I do not find that to be true. All examples I find, either you have to generate the database from EF or generate EF from the database.  That is disappointingly not database independent which to me would mean that my entity model could be applied to various databases of various architectures via the appropriate mappings. I found no explanations, tutorials, forum topics, or examples to support this. In fact, thus far, the best solution has been regeneration/migration of either the database or EF. This is highly inefficient.

**background**

I have a product to sell and want to tout dynamic database connectivity as an advantage. Now, I can do all of this with my own objects, classes, and SQL the old fashioned way, but it would be immensely quicker and more effective and I could get to market 3 times quicker if I can do this through EF. So, I'm hoping that I'm just missing something.

Forgive me for a lack of examples as I'm protecting my property and this is more a topic of design. But I will say it involves health care so forum participants can understand the magnitude of data that could be involved and why migration is in no way an option. Thanks.

I would tremendously appreciate any guidance.

解决方案

Hi,

It seems you mix several things here...

The database independance you see mentioned is that you are able to abstract away the underlying database. So the same code could run against SQL Server or Oracle (in reality you likely have to establish best practice and test as the underlying features are not always the same regardless of the db).

With mappings you could perhaps handle some schema differences for example if column names are not the same etc... At some point you are stuck if schema are different enough to just not be able to support your abstracted model. This is not something you'll do just for fun if you have some control over the db schema. Usually you'll use the same schema regardless of the actual underlying db.

Not sure if by "dynamic" you meant also have the user to alter the db and have EF automagically deal with this change ?

In short EF is to expose data as strongly typed objects to your code. My understanding is that your app have to work against a third party database schema you can't change and that you hoped to be able to use EF to map each of those schema to a single model used by your app ?

这篇关于在设计时更改EF数据库的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！