EntityTypeConfiguration - 什么是测试数据库映射的干净方法？
背景：
我公司当前的结构是使用 Plinqo/Linq to Sql 创建“数据访问对象”，然后使用一组自定义的 CodeSmith 模板来构建“业务对象”。长话短说，这两组对象紧密耦合，并且使用 Linq to SQL 会导致非常丑陋的解决方法。
Plinqo 模板在生成 dbml 后执行表到类的直接 1:1 映射。这会带来一些安慰，因为如果数据库发生更改，业务对象端（或应用程序端）会出现编译时错误。
我正在慢慢尝试证明 EF 4.1（代码优先）映射到现有架构的好处，但代码生成的这种“类型安全”已成为关键利益相关者心中的一个大问题。
问题：
因此，在实体框架 4.1 中，我首先使用代码来映射到现有数据库。
- Poco 域对象
- 每个映射的
EntityTypeConfiguration您建议使用什么测试项目来确保到模式的映射是健全的？我应该创建一个单元测试项目并检索每个对象还是有更好的方法？
谢谢！
Background:
My company's current structure is using Plinqo/Linq to Sql to create "data access objects", and then use a custom set of CodeSmith templates to build "business objects". To make a very long story short, these two sets of objects are very tightly coupled and, with Linq to SQL, lead to pretty ugly workarounds.
The Plinqo templates do a direct 1:1 mapping of table to class after generating the dbml. This leads to some comfort in that if the database changes, there is a compile-time error on the business object side (or application side).
I am slowly trying to prove out the benefits of EF 4.1 (Code First) to map to the existing schema, but this "type safety" of code generation has come up as a big issue in a key stakeholder's mind.
Problem:
So in entity framework 4.1, I am using code first to map to the existing database.
- Poco domain objects
- EntityTypeConfiguration for each mapping
What would you suggest as a test project for ensuring that the mapping to the schema is sound? Should I just create a unit test project and do retrievals of each object or is there a better way?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我使用了一个基本通用集成测试来执行 CRUD 操作，派生测试仅包含用于创建实体和验证每个操作结果的方法。每个测试方法都在未提交的事务范围内运行，因此测试数据库仍处于初始状态。
在您开始使用存储库并且不再使用单一实体类型而是开始使用聚合根的情况下，这可以进一步改进。在这种情况下，创建正确的集成测试来操作聚合根非常方便。
I used one base generic integration test performing CRUD operations and derived tests only contained methods for creating entity and validating results of each operation. Each test method run in transaction scope which didn't commit so the test database was still in initial state.
This can be further improved in scenarios where you start to use repositories and instead of working with single entity types you will start to work with aggregate roots. In such case creating correct integration tests manipulating aggregation roots is very handy.