We have a custom program that generates all the stored procs and classes for the Data Tier. Where will I put the generated classes?

Question

This is more of an architectural question regarding MVC and Data Access:

We have a custom program that generates all the stored procs and classes for the Data Tier from the MS SQL database. It's pretty nice as it generates a base class with the basic CRUD operations which includes ForeignKey reads. It also generates the plural version of the class to return the collections of objects.

For the next phase of our application we are planning on using MVC but we were hoping to continue using this great tool. Where will I put the generated classes in my new MVC application? I have seen people create an Infrastructure folder for their data access logic.

Is it a good idea to continue using this tool or should we be converting to the Entity Framework?

Also if the DAL is returning my objects and lists of objects what will I put in my Model layer?

Answer 1

It lives in the Model part of MVC.

where you physically put those generated classes? It doesn't really matter as far as MVC is concerned. However it makes sense to group things into logical places. But MVC wise, you could have an entire MVC application in 1 file.

Answer 2

Tool that you are using generates entities. Entity is a domain model that gets persisted. We have a similar tool and it resides in the entity framework project as it uses T4 templates. It needs to be part of entity framework project because it requires EDMX to run T4 templates.

Once the tool generates entities, we copy them into the domain layer project. I would never put entities into the DAL layer - it doesn't make sense in a domain driven design. How you wire things up is entirely up to you. If your entities are coupled to the data access framework (such as LINQ-to-SQL in old days), then you have a problem as all of a sudden your data access logic is leaking into your domain layer.

Once the tool generates stored procedures, tables and supporting components we move them into the ADO project. We are happy doing it manually. When the need comes, we might automate it.

With regards to your MVC application, domain models, and especially entities shouldn't be leaked into presentation layer. MVC should be working with view models. In some cases your view model will be an identical copy of a domain model, but don't be fooled - it might not always be the case.

Normally you would query the data through ADO or entity framework. You would then take the result and pass it to your presentation layer. When you do this you might want to convert result into DTO or pass the domain model directly (I normally avoid second option). Then in your presentation layer you take the DTO or domain model and convert it to the view model. Finally, M in MVC normally means view model, as opposed to domain model.