Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

How to avoid declaring database fields twice, once in database, once in a repository/model?

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?

like image 658
bevacqua Avatar asked Jan 21 '23 02:01

bevacqua


2 Answers

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.

like image 152
StriplingWarrior Avatar answered Feb 07 '23 12:02

StriplingWarrior


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

like image 44
alexandrekow Avatar answered Feb 07 '23 12:02

alexandrekow