EF模式第一或代码优先方法？ [英] EF Model First or Code First Approach?

问题描述

我知道这个问题已经被问过很多次了，因为我已经阅读了关于优缺点的主题的很多帖子，但是我仍然不能决定哪种方法适合我。我非常新的网络编程，来自SQL DB管理员/报告写作背景。我决定尝试建立自己的网站，可能最终可能会有30-40个表可能在将来更多。

我已经看了两种方法，我做因为我喜欢设计师的简单性，而且我喜欢在前面看到整个模型，它显示了一个快照中的整体画面。此外，我不是一个强大的程序员，我对使用DbContext生成器模板生成POCO的方式印象深刻，并且执行所有类之间的所有链接。

然而，尽管我喜欢模特儿第一方法我觉得有一些回顾，我不知道他们是否是实际的缺点，或者我不太了解模型的第一种方法和代码第一种方法，因为我还是很新的

我犹豫使用Model First方法的原因是：

主要是因为我正在努力寻找使用MVC 3的Model第一种方法的教程。我使用DbContext找到的最好的教程是Julie Lerman，但是她并没有覆盖使用数据注释和重要的好友类，进行其他重新生成POCO时不会丢失的更改。大多数教程MVC 3相关似乎都使用了Code的第一种方法。大多数人都说这是因为导师不想专注于EF，而是在提示中显示更多的MVC。我个人认为这是因为微软在其他方面支持Code First方法：）

- 如果创建好友类是好习惯，为什么我找不到很多教程显示这为MVC 3？ Buddy类是View Models的另一个名称吗？为什么我找不到微软的任何教程显示这些使用MVC 3的好友/视图模型？

- 我正在尝试做一个基本的1到1关系2张桌子之间。首先，在模型中，您必须将每个表的身份密钥设置为相同的字段，而不是在其中一个表中使用FK，当您有3个或更多个表之间通过1到1个关系链接时，可能会有点混乱。在代码中，这样做的一个方法是使用模型构建器并手动设置。我想在MF中，你可以通过进入我不喜欢做的XML来改变关系。

- 更多支持/帮助代码第一个问题

我犹豫使用Code First方法的原因是：

一个新手编码器

- 随着项目扩展，我看到很难跟踪表和关系。

没有模型图，我不得不说我真的很喜欢这个想法。

- 通过配置类将数据库映射到数据库我发现不可能：）。 >

- 更新表将需要更改代码和数据库。在模型中，首先只有一个模型的更改将自动更新数据库和代码，表示如果您使用好友类，您可能还需要更新这些。

此外，现在我看到人们在某种程度上结合了Code First和Database的第一种方法，因为您不会让Code First生成数据库，而是手动创建数据库，并使用代码优先API到EF。

我的头部正在旋转所有的选项和缺点以及利弊。我只想继续创建我的网站，而不是考虑采取哪种方法。
任何人都可以给我一些洞察，认为他们认为最好的方法是基于我所说的和/或他们认为将来会是更多的主流？

非常感谢dave

解决方案

这是太长的问题。你应该在下次将你的问题分解成多个单独的问题。

代码优先x模型首先x数据库优先

你是一个数据库的人，所以你最好的方法是一个增量数据库 - 第一种方法，你可以在数据库（或VS数据库工具）中定义数据，并从数据库更新你的模型。这将为您提供对数据库的大量控制，并允许您逐渐构建应用程序和数据库。为什么我认为你会喜欢它：

• 你以前做过SQL DB Admin - 你可能知道有关数据库的一些事情，以及如何设计它们表现 - EF不会为您做任何事情。 EF不会为您创建索引等。


• 30-40表意味着您不会在一次拍摄中构建模型。您将从小型模型开始，不断增长。一旦您开始更改数据库或添加初始化数据，您将不想丢失这些更改和数据。首先，首先允许删除整个数据库，并从头开始重新创建。 Model-first允许逐步构建DB，但需要实体设计器数据库生成功能包装和VS 2010 Premium或Ultimate（$ 5.000- $ 10.000）。

更多关于 DB首先，Model First和Code first 之间的差异。另一个答案描述了代码之间的差异首先和设计师合作。

DbContext API +数据库优先+流畅映射

我会称之为最难的方式。您将首先定义数据库，您将使用DbContext流畅的API或数据注释来定义映射。这需要很好的了解EF和DbContext API中使用的默认约定的映射背后的所有原则。它将给你很好的和明确的控制映射，但它是最多的工作要做。这绝对是最难的方式。此外，它不是使用的，因为DbContext API主要是为代码优先方法创建的。

DbContext API x ObjectContext API

一旦开始使用EDMX（实体设计器），您可以选择使用DbContext Generator T4模板或POCO Generator T4模板。决定取决于你 - 你可以使用DbContext API（第一个模板）或者ObjectContext API（第二个模板），这是更好的记录，你也可以使用两本好书：

• 编程实体框架


• 实体框架接收

所有关于ObjectContext API的知识都来自这些书籍，作者的博客和实践+反射器。

DbContext API目前没有任何书。您可以检查一些主要网站以获取有关信息：

• ADO.NET团队博客




• Morteza Manavi的博客

我所知道的关于DbContext API的是来自这些博客和实践+ Reflector。

即使您使用代码，您仍然可以使用类图来可视化您的类图（它与EDMX不一样，但足以获得大图）。

搜索堆栈溢出或 MSDN论坛将为您提供有关两种API的大多数问题的答案。

MVC 3

没有具体使用MVC 3的实体框架。数据验证注释的好友类被认为是不好的做法。伙伴类是用作实体上的元数据持有人的单独类。视图模型是用于在控制器和视图之间传输数据的类。视图模型应具有每个视图，并具有自己的验证注释，因为在使用相同实体类型时，通常需要在应用程序的不同屏幕中进行不同的验证 - 例如编辑和插入屏幕可以具有不同的验证要求。

尽管事实上它不被认为是良好的做法，但对实体添加验证是可能的 - 您可以

一对一关系

是EF需要仅在主键顶部。原因是EF不支持唯一的键/约束。没有办法解决这个问题，在数据库中使用唯一的密钥不会改变它。

I know this question has been asked numerous times before as I’ve read quite a few posts on the topic about the pros and cons etc but I still can’t decide which approach is right for me. I’m very new to web programming and come from a SQL DB Admin / report writing background. I’ve decided to try build my own website which may end up having 30 -40 tables maybe more in the future.

I’ve looked at both approaches and I do favour Entity Model approach only because I like simplicity of the designer and I like seeing the whole model in front me, it shows the overall picture in one snapshot. Also, me not being a strong programmer I am impressed with the way it generates the POCO’s using the DbContext generator template and does all the linking between the classes.

However, although I like the Model First Approach I feel there are some draw backs, I’m not sure if they are actual drawbacks or I just don’t know enough about the model first approach and code first approach as I’m still very new to this.

The Reasons that I am hesitant to use the Model First approach are:

-Mainly because I am struggling to find tutorials on the Model first approach using MVC 3. The best tutorial I’ve found using the DbContext is by Julie Lerman but she doesn’t cover buddy classes which are important for using data annotations and making other changes that aren’t lost when you regenerate the POCOs . Most tutorials MVC 3 related seem to use the Code first approach. Most people say this is because the tutor doesn’t want to focus on EF but rather show more MVC in the tuts. I personally think it’s because Microsoft is championing the Code First methodology over the others :)

-If it’s good practice to create buddy classes why can’t I find many tutorials showing this for MVC 3? Are Buddy Classes another name for View Models? And why can’t I find any tutorials by Microsoft showing these buddy/view models in use with MVC 3?

-I was trying to do a basic 1 to 1 relationship between 2 tables. In model first you have to set the identity keys of each table to the same field rather than using a FK in one of the tables, which may get a little confusing when you have 3 or more tables linked to each other by 1 to 1 relationships. In code first a way around this is use the model builder and set it up manually. I think in MF you can change the relationship by going into the XML which I am not keen on doing at all.

-More support/help on code first problems

The reasons I am hesitant to use the Code First approach are:

-I’m a novice coder.

-I see it getting quite difficult to keep track of tables and relationships as the project expands.

-There is no Model diagram and I have to say I really do like this idea.

-Mapping entities to the database via configuration classes I find impossible :).

-Updating a table will require a change to the code and the DB. In Model first only one change to the model which will automatically update the DB and Code having said that if you’re using buddy classes you may have to update these as well.

Also now I see people are somewhat combining Code First and Database first approaches, in that you don’t let Code First generate your database but manually create a database and use code first API to EF to get to it.

My head is spinning with all the options and drawbacks and pros and cons. I just want to get on with creating my website and not ponder on which approach to take. Can anyone give me some insight on which approach they think is best based on what I’ve said and/or what they think will be more main stream in the future?

Many thanks dave

解决方案

This is too long question. You should break your problem into multiple separate questions next time.

Code-first x Model-first x Database-first

You are a database guy so the best approach for you is an incremental database-first approach where you define the stuff in DB (or VS Database tools) and update your model from the database. This will give you a big control over your database and allow you building the application and the DB incrementally. Why I think you will like it:

• You did SQL DB Admin before - you probably know something about DB and how to design them for a performance - EF will not do anything from this for you. EF will not create indexes for you etc.
• 30-40 tables means that you will not build the model in one shoot. You will start with the small model and continuously grow it. Once you start making changes in DB or adding initialization data you will not want to lose these changes and the data. Code-first allows only deleting the whole database and recreating it from scratch. Model-first allow building the DB incrementally but you need Entity Designer Database Generation Power pack and VS 2010 Premium or Ultimate ($5.000-$10.000).

More about differences between DB first, Model first and Code first. Another answer describes differences between code-first and working with designer.

DbContext API + Database-first + Fluent mapping

I would call this the hardest way to go. You will the define database first and you will use DbContext fluent API or data annotations to define mapping. This requires good understanding of EF and all principles behind the mapping + understanding of default convention used in DbContext API. It will give you nice and explicit control over mapping but it is the most work to do. It is definitely the hardest way to go. Also it is not supposed usage because DbContext API was primarily created for code-first approach.

DbContext API x ObjectContext API

Once you start using EDMX (entity designer) you have a choice to use either DbContext Generator T4 template or POCO Generator T4 template. Decision is up to you - you can use either DbContext API (first template) or ObjectContext API (second template) which is much better documented and you can also use two great books:

• Programming Entity Framework
• Entity Framework Recepies

All I know about ObjectContext API is from these books, authors' blogs and practice + Reflector.

DbContext API doesn't currently have any book. You can check some main sites to get info about it:

• ADO.NET Team blog
• Julia Lerman's blog
• Morteza Manavi's blog

All I know about DbContext API is from these blogs and practice + Reflector.

Even if you are using code first you can still use class diagram to visualize your class diagram (it is not the same as EDMX but it is enough for getting the big picture).

Searching on Stack Overflow or MSDN forum will give you answers on most problems you will have with both APIs.

MVC 3

There is nothing specific with using entity framework with MVC 3. Buddy classes for data validation annotations are considered bad practice. A buddy class is separate class used as a metadata holder applied on the entity. A view model is the class used to transfer data between controller and view. View model should be specific per view with its own validation annotations because you usually need different validations in different screens of your application when working with the same entity type - for example edit and insert screen can have different validation requirements.

Despite the fact it is not considered as the good practice, adding validation to entities is possible - you can either create buddy class for each your entity manually or you can try to modify T4 template to generate annotations for you directly (well this is hard).

One-to-one relation

Yes EF requires creating one-to-one relation only on top of primary keys. The reason is that EF doesn't support unique keys / constraints. There is no way around this and using unique keys in database will not change it.

这篇关于EF模式第一或代码优先方法？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！