如何避免两次声明数据库字段，一次在数据库中，一次在存储库/模型中？
我最近开始阅读 Pro ASP.NET MVC Framework。
作者谈论了创建存储库以及使用接口来设置进行快速的自动化测试，这听起来很棒。
但它带来的问题是，必须为数据库中每个表的所有字段声明两次：一次在实际数据库中，一次在 C# 代码中，而不是使用 ORM 自动生成 C# 数据访问类。
我确实知道这是一个很好的实践，并且使 TDD 看起来也很棒。但我的问题是：
是否有任何解决方法必须在数据库和 C# 代码中两次声明字段？难道我不能使用自动生成 C# 代码但仍然允许我执行 TDD 的东西，而不必在 C# 中手动创建所有业务逻辑并为每个表创建一个存储库（以及一个假的存储库）吗？
I recently began reading Pro ASP.NET MVC Framework.
The author talks about creating repositories, and using interfaces to set up quick automated tests, which sounds awesome.
But it carries the problem of having to declare yourself all the fields for each table in the database twice: once in the actual database, and once in the C# code, instead of auto-generating the C# data access classes with an ORM.
I do understand that this is a great practice, and enables TDD which also looks awesome. But my question is:
Isn't there any workaround having to declare fields twice: both in the database and the C# code? Can't I use something that auto-generates the C# code but still allows me to do TDD without having to manually create all the business logic in C# and creating a repository (and a fake one too) for each table?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我明白你的意思：你声明由存储库检索的大多数 POCO 类看起来很像由 ORM 框架自动生成的类。因此，很容易重用这些数据访问类，就好像它们是业务对象一样。
但根据我的经验，我在业务逻辑中所需的数据很少与数据访问类完全一样。通常，我要么需要数据对象中的某些特定数据子集，要么需要通过将几个数据对象连接在一起而生成的某种数据组合。如果我愿意再花两分钟实际构建我想要的 POCO，并创建一个接口来表示我计划使用的存储库方法，我发现当我需要时，代码最终会更容易重构改变业务逻辑。
I understand what you mean: most of the POCO classes that you're declaring to have retrieved by repositories look a whole lot like the classes that get auto-generated by your ORM framework. It is tempting, therefore, to reuse those data-access classes as if they were business objects.
But in my experience, it is rare for the data I need in a piece of business logic to be exactly like the data-access classes. Usually I either need some specific subset of data from a data object, or some combination of data produced by joining a few data objects together. If I'm willing to spend another two minutes actually constructing the POCO that I have in mind, and creating an interface to represent the repository methods I plan to use, I find that the code ends up being much easier to refactor when I need to change business logic.
如果您使用Entity Framework 4，您可以从数据库自动生成POCO对象。 （链接)
然后您可以实现一个通用的 IRepository 及其通用的 SqlRepository，这将允许您拥有所有对象的存储库。此处对此进行了解释： http://msdn.microsoft.com/en-us/ff714955 .aspx
这是实现您想要的目标的一种干净方法：您只需在数据库中声明一次对象，自动生成它们，并且可以通过存储库轻松访问它们（此外，您可以进行 IoC 和单元测试： ) )
我建议您阅读本书的第二版，它是纯金版，并更新了 MVC 2 中引入的新功能
http://www.amazon.com/ASP-NET-Framework-Second-Experts- Voice/dp/1430228865/ref=sr_1_1?s=books&ie=UTF8&qid=1289851862&sr=1-1
您还应该阅读 MVC3 中引入的新功能，该功能现已在 RC 中（有是一个非常有用的新视图引擎） http://weblogs.asp.net/scottgu/archive/2010/11/09/announcing-the-asp-net-mvc-3-release-candidate.aspx
If you use Entity Framework 4, you can generate POCO object automatically from the database. ( Link)
Then you can implement a generic IRepository and its generic SqlRepository, this will allow you to have a repository for all your objects. This is explained here : http://msdn.microsoft.com/en-us/ff714955.aspx
This is a clean way to achieve what you want: you only declare your object once in your database, generate them automatically, and can easily access them with your repository (in addition you can do IoC and unit test :) )
I recommend you to read the second edition of this book which is pure gold and updated with the new features introduced in MVC 2
http://www.amazon.com/ASP-NET-Framework-Second-Experts-Voice/dp/1430228865/ref=sr_1_1?s=books&ie=UTF8&qid=1289851862&sr=1-1
And you should also read about the new features introduced in MVC3 which is now in RC (there is a new view engine really useful) http://weblogs.asp.net/scottgu/archive/2010/11/09/announcing-the-asp-net-mvc-3-release-candidate.aspx
您不会两次声明业务逻辑。只是这个业务逻辑被抽象在一个接口后面，在这个接口的实现中你可以做任何你想做的事情：访问数据库，从文件系统读取，从网址聚合信息，......这个接口允许弱耦合控制器和存储库的实现等简化了 TDD。将其视为控制者和企业之间的合同。
You are not declaring the business logic twice. It's just that this business logic is abstracted behind an interface and in the implementation of this interface you can do whatever you want : hit the database, read from the filesystem, aggregate information from web addresses, ... This interface allows weaker coupling between the controller and the implementation of the repository and among other simplifies TDD. Think of it as a contract between the controller and the business.