EF 模型优先还是代码优先方法?
我知道这个问题之前已经被问过很多次了,因为我已经阅读了很多关于该主题的利弊等帖子,但我仍然无法决定哪种方法适合我。我对 Web 编程非常陌生,并且有 SQL DB 管理/报告编写背景。我决定尝试建立自己的网站,将来可能会有 30 -40 张桌子,甚至更多。
我已经研究了这两种方法,并且我确实喜欢实体模型方法,只是因为我喜欢设计器的简单性,并且我喜欢看到我面前的整个模型,它在一个快照中显示了整体图片。另外,我不是一个强大的程序员,它使用 DbContext 生成器模板生成 POCO 并在类之间进行所有链接的方式给我留下了深刻的印象。
然而,虽然我喜欢模型优先方法,但我觉得它有一些缺点,我不确定它们是否是真正的缺点,或者我只是对模型优先方法和代码优先方法了解不够,因为我仍然非常了解模型优先方法和代码优先方法。对此不熟悉。
我对使用模型优先方法犹豫不决的原因是:
- 主要是因为我很难找到有关使用 MVC 3 的模型优先方法的教程。我找到的使用 DbContext 的最佳教程是由 Julie Lerman 撰写,但她没有介绍伙伴类,这些类对于使用数据注释和进行重新生成 POCO 时不会丢失的其他更改非常重要。大多数与 MVC 3 相关的教程似乎都使用代码优先方法。大多数人说这是因为导师不想专注于 EF 而是在教程中展示更多 MVC。我个人认为这是因为 Microsoft 比其他方法更拥护 Code First 方法 :)
- 如果创建伙伴类是很好的做法,为什么我找不到很多针对 MVC 3 展示这一点的教程?好友类是视图模型的别称吗?为什么我找不到 Microsoft 提供的任何教程来展示这些伙伴/视图模型与 MVC 3 的使用?
-我试图在两个表之间建立基本的一对一关系。首先在模型中,您必须将每个表的标识键设置为同一字段,而不是在其中一个表中使用 FK,当您有 3 个或更多表通过 1 对 1 关系相互链接时,这可能会有点混乱。在代码优先中,解决此问题的方法是使用模型构建器并手动设置。我认为在 MF 中,您可以通过进入 XML 来更改关系,但我根本不热衷于这样做。
- 有关代码优先问题的更多支持/帮助
我对使用代码优先方法犹豫不决的原因是:
- 我是一名新手编码器。
-我发现随着项目的扩展,跟踪表和关系变得非常困难。
-没有模型图,我不得不说我真的很喜欢这个想法。
-通过配置类将实体映射到数据库我发现不可能:)。
-更新表将需要更改代码和数据库。在模型中,首先对模型进行一次更改,该更改将自动更新数据库和代码,也就是说,如果您使用伙伴类,您可能也必须更新这些。
现在我还看到人们在某种程度上将 Code First 和 Database First 方法结合起来,因为您不会让 Code First 生成数据库,而是手动创建数据库并使用 Code First API 到 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
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
这是一个太长的问题。下次你应该将你的问题分成多个单独的问题。
代码优先 x 模型优先 x 数据库优先
您是一名数据库专家,因此最适合您的方法是增量数据库优先方法,您可以在 DB(或 VS 数据库工具)中定义内容并从数据库更新模型。这将使您对数据库有很大的控制权,并允许您逐步构建应用程序和数据库。为什么我认为您会喜欢它:
详细了解数据库优先、模型优先和首先编码。另一个答案描述了代码之间的差异-首先与设计师合作。
DbContext API + 数据库优先 + 流畅映射
我认为这是最难的方法。您将首先定义数据库,然后使用 DbContext Fluent API 或数据注释来定义映射。这需要对 EF 以及映射背后的所有原则有很好的理解+对 DbContext API 中使用的默认约定的理解。它将为您提供对映射的良好且明确的控制,但这是要做的最多的工作。这绝对是最难走的路。而且它也不应该被使用,因为 DbContext API 主要是为代码优先方法创建的。
DbContext API x ObjectContext API
一旦开始使用 EDMX(实体设计器),您就可以选择使用 DbContext Generator T4 模板或 POCO Generator T4 模板。决定取决于您 - 您可以使用 DbContext API(第一个模板)或 ObjectContext API(第二个模板),后者有更好的文档记录,您还可以使用两本好书:
我对ObjectContext API的了解都是来自这些书籍、作者的博客和实践+Reflector。
DbContext API 目前没有任何书籍。您可以查看一些主要网站以获取相关信息:
我对DbContext API的了解都是来自这些博客和实践+Reflector。
即使您首先使用代码,您仍然可以使用类图来可视化您的类图(它与 EDMX 不同,但足以了解全局)。
在 Stack Overflow 或 MSDN 论坛 上搜索将为您提供以下问题的答案使用这两个 API 时遇到的大多数问题。
MVC 3
将实体框架与 MVC 3 一起使用没有什么特别之处。用于数据验证注释的好友类被认为是不好的做法。伙伴类是用作应用于实体的元数据持有者的单独类。视图模型是用于在控制器和视图之间传输数据的类。视图模型应该针对每个视图具有自己的验证注释,因为在使用相同的实体类型时,您通常需要在应用程序的不同屏幕中进行不同的验证 - 例如,编辑和插入屏幕可能有不同的验证要求。
尽管事实上这不被认为是良好实践,但向实体添加验证是可能的 - 您可以手动为每个实体创建伙伴类或者您可以尝试修改T4模板以直接为您生成注释(这很难)。
一对一关系
是 EF 要求仅在主键之上创建一对一关系。原因是 EF 不支持唯一键/约束。没有办法解决这个问题,并且在数据库中使用唯一键不会改变它。
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:
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:
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:
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.
这相对简单。如果您不关心数据库模型,请先使用代码。如果这样做,请首先使用模型(或首先使用数据库)。这仅取决于您的重点所在,以数据为中心还是以代码为中心。
It's relatively simple. If you don't care about the database model, use code first. If you do, use Model first (or Database First). It just depends on where your focus lies, data centric or code centric.
+
= 首先使用模型
这可能是因为代码优先就像是一个新来的孩子。这就是为什么 MVC3 大多都是代码优先的教程。模型优先的历史“悠久”,并且可能是 MVC2 时代最受欢迎的解决方案。
顺便说一句:你已经知道我的意见,你应该使用你最喜欢或觉得最舒服的东西(正如我上次问你这个问题时告诉你的),但我只是想在这里添加一些东西:)
评论后编辑:
看看这些东西,这将对您首先编写代码有很大帮助:
为 ASP.NET MVC 应用程序创建实体框架数据模型(1 / 10)
搭建你的支架带有 MvcScaffolding 包的 ASP.NET MVC 3 项目
++ 这些来自 MIX11 频道 9 的精彩视频:
Scott Hanselman 一如既往地以他出色的方式展示新东西
Steve Sanderson 展示 MvcScaffolding 的强大功能
+
= use model first
This might be because the code-first is something like a new kid in the block. That's why there are mostly code-first tutorial for MVC3. Model-first is 'much' older and was probably most favourited solution in times of MVC2.
Btw: You already know my oppinion, that you should use, what you like best or find most comfortable (as I told you last time you asked about this), but I just wanted to add something here :)
Edit after comments:
Take a look at these things, that will help you with code first a lot imo:
Creating an Entity Framework Data Model for an ASP.NET MVC Application (1 of 10)
Scaffold your ASP.NET MVC 3 project with the MvcScaffolding package
++ these great videos from MIX11 at channel9:
Scott Hanselman showing new stuff in his awesome way as usually
Steve Sanderson showing power of MvcScaffolding
如果这是模型优先的主要问题,您可以使用任何版本的 MVC 中的模型优先示例。 MVC 处理“模型”的方式在各个版本之间并没有真正的不同。当然,视图模型等有所增强,但您应该可以接受旧的教程。
我首先喜欢代码,因为我觉得有数据库模型和领域模型,它们有不同的用途。数据库组织是为了数据库的性能和大小,而不是为了帮助您的应用程序。拥有自己的模型使您可以专注于应用程序中的状态需求,而不管数据库如何。
现在,您可以首先从模型进入该模型,但您更有可能以这种方式考虑数据库而不是您的需求......尤其是。如果您是这方面的新手。
只是我的2分钱。
You can use the model first examples from any version of MVC, if that is your primary issue with model first. The way MVC handles "models" is not really different across versions. Sure, there are enhancements to the view model, etc., but you should be fine with older tutorials.
I prefer the code first, as I feel there are database models and domain models and they serve different purposes. Database organization is for performance and size on the database and not to help your application. Having your own model allows you to focus on state needs in your application, regardless of the database.
Now, you can get to this model from model first, but you are more likely to think about the database than your needs in this manner ... esp. if you are a newbie at this.
Just my 2 cents.