EDMX图中使用实体框架4.1代码优先优于模型/数据库优先的优点和缺点是什么?
我试图充分理解使用EF 4.1构建数据访问层的所有方法。我使用存储库模式和IoC。
我知道我可以使用代码优先的方法:手动定义实体和上下文,并使用ModelBuilder对模式进行微调。
我还可以创建一个EDMX图并选择一个代码生成步骤,该步骤使用T4模板来生成相同的POCO类。
在这两种情况下,我最终得到的POCO对象是ORM不可知的,而上下文则来自DbContext。
数据库优先似乎是最有吸引力的,因为我可以在企业管理器中设计数据库,快速同步模型并使用设计器对其进行微调。
那么这两种方法有什么不同呢?仅仅是VS2010 vs企业管理器的偏好问题吗?
我认为区别在于:
代码首先
非常流行,因为核心程序员不喜欢任何类型的设计器,并且在EDMX xml中定义映射太复杂了。
对代码的完全控制(没有难以修改的自动生成代码)。
一般情况下,您不需要为DB操心。DB只是一个没有逻辑的存储。EF将处理创建,你不想知道它是如何工作的。
对数据库的手动更改很可能会丢失,因为您的代码定义了数据库。
数据库的第一
Very popular if you have DB designed by DBAs, developed separately or if you have existing DB.
You will let EF create entities for you and after modification of mapping you will generate POCO entities.
If you want additional features in POCO entities you must either T4 modify template or use partial classes.
Manual changes to the database are possible because the database defines your domain model. You can always update model from database (this feature works quite well).
I often use this together VS Database projects (only Premium and Ultimate version).
第一个模型
IMHO popular if you are designer fan (= you don't like writing code or SQL).
You will "draw" your model and let workflow generate your database script and T4 template generate your POCO entities. You will lose part of the control on both your entities and database but for small easy projects you will be very productive.
If you want additional features in POCO entities you must either T4 modify template or use partial classes.
Manual changes to database will be most probably lost because your model defines the database. This works better if you have Database generation power pack installed. It will allow you updating database schema (instead of recreating) or updating database projects in VS.
我希望在EF 4.1的案例中,还有其他几个与代码优先和模型/数据库优先相关的特性。首先在Code中使用的Fluent API并不能提供EDMX的所有功能。我希望像存储过程映射、查询视图、定义视图等功能在首先使用模型/数据库和DbContext(我还没有尝试过)时可以工作,但在代码中不能。
引用http://www.itworld.com/development/405005/3-reasons-use-code-first-design-entity-framework的相关部分
3 reasons to use code first design with Entity Framework
1) Less cruft, less bloat
Using an existing database to generate a .edmx model file and the
associated code models results in a giant pile of auto generated code.
You’re implored never to touch these generated files lest you break
something, or your changes get overwritten on the next generation. The
context and initializer are jammed together in this mess as well. When
you need to add functionality to your generated models, like a
calculated read only property, you need to extend the model class.
This ends up being a requirement for almost every model and you end up
with an extension for everything.
With code first your hand coded models become your database. The exact
files that you’re building are what generate the database design.
There are no additional files and there is no need to create a class
extension when you want to add properties or whatever else that the
database doesn't need to know about. You can just add them into the
same class as long as you follow the proper syntax. Heck, you can even
generate a Model.edmx file to visualize your code if you want.
2) Greater Control
When you go DB first, you’re at the mercy of what gets generated for
your models for use in your application. Occasionally the naming
convention is undesirable. Sometimes the relationships and
associations aren't quite what you want. Other times non transient
relationships with lazy loading wreak havoc on your API responses.
While there is almost always a solution for model generation problems
you might run into, going code first gives you complete and fine
grained control from the get go. You can control every aspect of both
your code models and your database design from the comfort of your
business object. You can precisely specify relationships, constraints,
and associations. You can simultaneously set property character limits
and database column sizes. You can specify which related collections
are to be eager loaded, or not be serialized at all. In short, you are
responsible for more stuff but you’re in full control of your app
design.
3)Database Version Control
This is a big one. Versioning databases is hard, but with code first
and code first migrations, it’s much more effective. Because your
database schema is fully based on your code models, by version
controlling your source code you're helping to version your database.
You’re responsible for controlling your context initialization which
can help you do things like seed fixed business data. You’re also
responsible for creating code first migrations.
When you first enable migrations, a configuration class and an initial
migration are generated. The initial migration is your current schema
or your baseline v1.0. From that point on you will add migrations
which are timestamped and labeled with a descriptor to help with
ordering of versions. When you call add-migration from the package
manager, a new migration file will be generated containing everything
that has changed in your code model automatically in both an UP() and
DOWN() function. The UP function applies the changes to the database,
the DOWN function removes those same changes in the event you want to
rollback. What’s more, you can edit these migration files to add
additional changes such as new views, indexes, stored procedures, and
whatever else. They will become a true versioning system for your
database schema.
数据库优先和模型优先没有真正的区别。
生成的代码是相同的,您可以结合这两种方法。例如,您可以使用设计器创建数据库,也可以使用sql脚本更改数据库并更新模型。
当你首先使用代码时,你不能在没有重新创建数据库和丢失所有数据的情况下改变模型。恕我直言,这个限制非常严格,不允许在生产中首先使用代码。目前它还不能真正使用。
代码的第二个次要缺点首先是模型构建器需要对主数据库的特权。如果您使用SQL Server Compact数据库或控制数据库服务器,这不会影响您。
代码的优点首先是非常干净和简单的代码。您可以完全控制这些代码,并可以轻松地修改和使用它作为您的视图模型。
我建议使用代码优先的方法,当你创建简单的独立应用程序,没有版本,并使用模型\数据库优先的项目,需要在生产中修改。
在SP1之前,使用大型机型的速度非常慢(SP1之后还没有尝试过,但据说现在很容易)。
我仍然先设计我的表,然后内部构建的工具为我生成poco,因此它承担了为每个poco对象执行重复任务的负担。
当你使用源代码控制系统时,你可以很容易地跟踪poco的历史,而使用设计器生成的代码就不那么容易了。
我的POCO有一个基础,这使得很多事情变得非常简单。
我有所有表的视图,每个基本视图为外键带来基本信息,我的视图POCO派生自我的POCO类,这是非常有用的。
最后,我不喜欢设计师。