重构：从自定义数据访问层swicthing到实体框架 [英] refactoring: swicthing from custom data access layer to Entity Framework
问题描述
我是一个.NET开发人员，并为重构项目的一部分，我有几个问题。
I am a .NET Developer and as part of a refactoring project, I have a few questions.
我们的软件目前使用的活动记录模式（一到的数据对象和业务对象之间的一对一映射）。坏的是，业务对象继承了数据对象，引起高度耦合层之间。
Our software is currently using an Active Record pattern (one to one mapping between the data objects and the business objects). The bad thing is that the business objects inherits from the data objects, inducing highly couple between the layers.
我们的目标是从我们的数据访问层（基于ADO.NET）实体框架切换。我们有约束不是突破code，使我们的旧应用程序仍然会编译和运行使用旧的数据访问层，同时允许我们使用EF新项目。
Our goal is to switch from our custom data access layer (based on ADO.NET) to Entity Framework. The constraint we have is not to break the code so that our older applications will still compile and run using the old data access layer while allowing us to use EF for the new projects.
这样做我的第一个想法就是要打破继承和拥有的数据对象作为业务对象的属性（和使用接口或抽象类，以数据对象注入，不管是我们的定制层或实体框架）。的属性将被从数据对象到业务对象这会像某种代理的访问数据对象的属性迁移。
My first idea to do so is to break the inheritance and have the data object as an attribute of the business object (and use an interface or abstract class in order to inject the data object, whether it is our custom layer or Entity Framework). The properties would be migrated from the Data objects to the business objects which would act like some kind of "proxy" to access the properties of the data objects.
请问这是一个可行的解决方案吗？这将仍然使用活动记录模式（我不喜欢这个有很多，因为我们的业务层已经变得相当大），所以如果您有任何其他的想法，请不要犹豫。
Would that be a viable solution ? That would still use the active record pattern (and I don't like this a lot, since our business layer has become quite large) so if you have any other idea, please don't hesitate.
我的另一个问题是关于实体框架生成。我们需要的实体属性具有相同的名称作为旧数据对象（我们将使用一个抽象类，以便允许业务对象来调用数据对象的属性，无论是我们的自定义数据对象或EF实体） 。什么将是实现这一目标的最佳途径？使用T4生成实体或有EF code第一种方式？
My other question is about the Entity framework generation. We need the entities properties to have the same name as the old data objects (we would use an abstract class in order to allow the business objects to call the properties of the data object, whether it is our custom data object or the EF entities). What would be the best way to accomplish that ? Using T4 to generate the entities or have an EF Code first approach ?
我对任何建议非常开放的，所以请不要犹豫，提出其他方法。感谢您的时间。
I am very open to any suggestion, so please do not hesitate to propose other approaches. Thanks for your time.
推荐答案
请问这是一个可行的解决方案的如果你将开始与实体框架一个新的项目，我会说：不是。因为实体框架是一个实现的库和工作单位的模式和活动记录的模式是完全不同的方法。
Would that be a viable solution ? If you would start a new project with Entity Framework I would say: No. Because Entity Framework is an implementation of the Repository and Unit Of Work pattern and Active Record pattern is a quite different approach.
即使您使用非POCO， EntityObject 与实体框架派生实体的实体不会成为真正的活动记录，因为持久性的特点， EntityObject 或 EntityCollection 暴露是有限的（设计，我相信）。 EntityObject 只支持更改跟踪和 EntityCollection 有一个像加载功能或 CreateSourceQuery 支持查询的特定集合。但是，你没有完整的的ObjectContext 手头发出任意查询，删除对象或保存更改。
Even if you use Non-POCO, EntityObject derived entities with Entity Framework the entities don't become really active records because the persistence features which EntityObject or EntityCollection expose are limited (by design, I believe). EntityObject just supports change tracking and EntityCollection has functions like Load or CreateSourceQuery which support queries on that specific collection. But you don't have the full ObjectContext at hand to issue arbitrary queries, delete objects or save changes.
EF 4.1和的DbContext 更不因为 EntityObject 支持这个了派生实体不容许的DbContext 。它具有持久性没有意识到实体纯粹的POCO方法。只有懒加载和变更跟踪哪知道的范围内代理，但是这仅仅是一个透明的功能在运行时，你不能对这个代理方面进行编程。
EF 4.1 and DbContext even don't support this anymore since EntityObject derived entities are not allowed with DbContext. It's a pure POCO approach with persistence unaware entities. There are only lazy loading and change tracking proxies which know the context, but that is only a "transparent" feature at runtime and you cannot program against this proxy context.
现在，你不开始一个新的项目，但有您必须遵守大型部件的架构。如果您的数据对象的基类（其中实现活动记录），类似于 LoadMe ， SaveMe ，
Now, you don't start with a new project but have an architecture you must respect in large parts. If your data object base classes (which implement Active Record) have methods like LoadMe, SaveMe, LoadCustomersContacts, etc. and you use these methods in your business/service layers and you cannot or don't want to change this layer, then you probably have to find a working Active Record approach with Entity Framework.
这是一个非标准的做法，有点对实体框架的架构。它提出了一些问题，例如：你是如何管理的关系方面创造和寿命反对一辈子？你是如何处理事务性和非事务性的行为？ （的SaveChanges 本身就是一个交易，你不能保存单行或实体，你总是保存完全什么在工作范围内/单位 - 修改，增加或删除。这可能不是与ADO.NET的Active Record的方法有今天的行为。）
This is a non-standard approach and a bit against the architecture of Entity Framework. It raises questions, for example: How do you manage context creation and lifetime in relation to object lifetime? How do you handle transactional and non-transactional behaviour? (SaveChanges is a transaction by itself and you cannot save single "rows" or entities, you always save completely what's in the context/unit of work - modified, added or deleted. This is probably not the behaviour that your Active Record methods with ADO.NET have today.)
如何做到这一点是什么呢？我不知道，我从来没有使用这种方法。尝试谷歌的实体框架和活动记录模式或东西，也许你觉得有点不说别这样！
How to do that exactly? I don't know, I've never used this approach. Try to google for "Entity Framework and Active Record pattern" or something and perhaps you find a bit which doesn't say "Don't do that!".
要你的另一个问题：我倒是preFER 的DbContext 与code-首先为便于开发（这就是它被做了）。但要知道，有哪个不支持code-首先，需要一个EDMX基础的解决方案（模型定义的函数就是其中之一，我相信，等等）的一些功能。同样映射到存储过程目前还不支持在的DbContext 。您可以通过发出的背景下原始的SQL语句，虽然它可以是一个解决此限制。
To your other question: I'd prefer DbContext with Code-First for the ease of development (that's what it was made for). But be aware that there are a few features which are not supported in Code-First and require an EDMX based solution ("Model-defined functions" is one of them, I believe, among others). Also mapping to Stored Procedures is not yet supported in DbContext. You can issue raw SQL statements through the context though which can be a workaround for this limitation.
这是我的看法。
BTW：欢迎计算器！你的问题是有问题的网站的格式，因为过于笼统，有些要求意见。我建议你拆你的问题分解成更小的部分，并建立独立的更小，更具体的问题，或许饰以小code片段，使之更加具体和切实的。你通常会得到这样的问题（比我上面布拉布拉更有价值响应）多个响应。好消息是：因为你想，你可以创建许多问题
BTW: Welcome to Stackoverflow! Your question is problematic for the format of this site because too general and a bit asking for "opinions". I would recommend you to split your problem down into smaller parts and create separate smaller and more specific questions, perhaps decorated with little code snippets to make it more concrete and tangible. You usually get more response to such questions (and more valuable response than my blabla above). The good news is: You can create as many questions as you want.
这篇关于重构：从自定义数据访问层swicthing到实体框架的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
