2010-08-16 82 views
0

使用实体框架(EF)和LINQ部署完整的应用程序后,接下来可能发生的情况是“先前包含/映射到应用程序中的EF的数据库”中的数据:实体框架下的维护任务

  1. 创建新表,其中包括为EF
  2. 删除了以前包含在EF
  3. 包括新字段表和EF还包括数据库现有的表。
  4. 从先前包含在EF中的现有表中删除字段
  5. 修改数据库中的字段(新类型或长度)并在EF中应用更改。

问题是:所有这些更改都可以在使用EF的应用程序中轻松/自动修改吗?

回答

1

您所描述的修改以及EF设计人员容易接受或使用的修改。继续并在数据库中进行更改。完成后,只需右键单击EF设计师界面,然后选择从数据库刷新EF模型。

更困难的部分将重新调整您的业务逻辑以符合新的数据模型。那些被删除/更改的实体/表和属性/属性将在Visual Studio中高亮显示,并且您必须访问每行代码才能更正它们。这可能在您的DAL/Repository中,并进入引用您的EF模型的任何程序集。

对于那些新的表/实体和属性或数据类型,您可以简单地合并并立即在代码中使用它们。

为了感受这将如何工作,请尝试更改一件事(删除一个实体/表或更改数据类型),然后执行我描述的步骤。根据您对多个更改的容忍程度,请考虑花费更长的时间逐个管理数据模型更改。

EF是否有机制或“最佳实践”让我们将BL与新模型对齐?

我不确定我是否理解你“将BL与新模型对齐”的意图。没有任何自动化的方法来“修复代码以适应实体新的外观”。你只会看到编译器错误。

如果您在询问如何防止数据库更改,我会说这是您在应用程序中做出的体系结构决策,并且没有任何BP。鉴于EF是一个ORM,一些开发人员会建议使用/使用EF为您创建的实体。一些开发人员建议使用它们,并创建partial class以扩展它们的行为(与数据库分开的新方法或属性)。一些开发人员想要创建一套全新的类和对象模型来表示类或使类看起来更像真实世界,而不是数据库如何构建数据模型。然后他们继续在EF实体和他们自己的POCO类之间创建映射代码 - 在每个版本之间进行转换。

我对此的建议是:对您的表/实体使用ORM的类,并在需要时/部分扩展其行为和数据。

+0

非常感谢您的快速回答,您提到了业务逻辑(BL)的一个非常重要的一点,所以请让我澄清一下,多想一想; EF是否有机制或“最佳实践”让我们将BL与新模式联系起来? – vizcayno 2010-08-16 18:48:13