作为代码现代化计划的一部分，我正试图找出一种方法来使用实体框架来增强（并最终取代）我们自己开发的ORM。 ORM本身距离前一步的SQL调用是一个巨大的进步，但是现在已经提升了基础架构的其余部分，我想开始逐步淘汰它。
为此，我试图弄清楚如何通过Entity框架构建类，以便它们的行为与当前ORM的行为类似。理想情况下，在重新设计类时不需要进行任何代码更改，我们将获得延迟加载和生成/更新类以便与数据库匹配的功能。
当前的ORM实际上是用于构建SQL语句的非常奇特的包装器。 Part p = new Part(12345);将执行select * from parts where partID = 12345，然后获取它返回的DataRow并使用反射来填充对象上的字段。当它保存时，它几乎完全相同 - 它需要所有字段并使用它来更新数据行，然后将其写回数据库。通常，当我们期望编辑时，它还会锁定数据库中的行。有点kludgy，但它的工作原理。
我正试图找出一种方法来使用Entity框架和模板以不需要持久数据上下文的方式自动生成我们的类。当前方法允许我们在需要的地方创建对象，根据需要传递它们，并且知道当它们更新时，数据库将更新以匹配该对象。我已经查看了各种各样的东西（根据标题），但我不知道我们可以使用哪种方法，以便在对象库之外不需要上下文。
有人能指出我正确的方向吗？
编辑：我可能会要求太多，或者试图将方形钉子插入圆孔中。让我简化我正在寻找的东西，将其剥离到最低限度。
有没有办法构建这个，所以我可以有一个在using (var context = new Context()) {}之外有效的CRUD类型对象，以便我可以将它传递给不相关的代码？我不在乎是否需要将其放回上下文中加载/保存它，只要它在它之外工作。
如果使用EF无法做到这一点，那么这种情况的正确设计模式是什么：一种形式打开另一种形式并传入发票。第二种形式采用Invoice，引导用户为其输入付款，并生成新的Payment对象。第一个表单采用该Payment对象，并根据它对Invoice进行进一步处理。然后，一切都会立即提交到数据库。
答案 0 :(得分：0)
POCO，POCO与Proxy或STE都不匹配您的架构。所有这些实体类型的要点是使您的实体持久性无知，但您的实体实现持久性。最接近您的模型的是旧的DataSet。
EF的中心点是背景。如果你想保持你的架构，每个实体都必须处理自己的上下文。这就是EF反模式。 EF期望您拥有上下文并使用上下文来获取和持久化实体 - 大多数EF功能都依赖于此模式。
答案 1 :(得分：0)
如果你真的想要延迟加载EF，那么肯定你需要创建EF DbContext / Object Context。我想通过删除不相关的代码（如持久性逻辑）将当前类转换为POCO类并不是什么大问题。我鼓励您通过执行操作EF上下文的服务层来抽象持久层，例如，您的表单调用服务层，服务层创建上下文实例和持久/反转数据。
答案 2 :(得分：0)
如果您使用POCO并关闭上下文的代理生成（或者在处置上下文之后将其分离），那么您的实体将在using context子句之外有效。
如果您的对象具有您需要在using context子句之外有效的集合属性，则需要在查询中使用include或在离开using context子句之前填写其他查询。