Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
add comment

2 Answers

up vote 0 down vote accepted

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.

share|improve this answer
    
Everything can be in one file, but the common practice is to keep them separate from the views and controllers. –  DFord Dec 2 '13 at 23:00
    
for sure....the point I'm making is from a MVC point of view it doesn't make any difference ( even though some MVC frameworks might assumes a particular layout of resources ). There's no standard, and common approaches depend a bit on specific frameworks / language / enviroments. –  Keith Nicholas Dec 2 '13 at 23:06
    
thanks mate, I will probably keep it in a separate DAL assembly and then use ViewModels in the Models Folder that access these DAL objects such as CreateUserViewModel :) technically speaking the Model can be spread across multiple assemblies right? –  user3012037 Dec 3 '13 at 0:50
    
you can if you wish and it seems a logical thing to do... very hard for me to comment as I don't know your system so can't really given much of an opinion on what are good and bad options. The only thing I'd have a play with entity framework and get it doing what you want as a exploratory exercise to see if it will work better for you or not. –  Keith Nicholas Dec 3 '13 at 1:12
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.