2

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?

2 Answers 2

0

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.

4
  • Everything can be in one file, but the common practice is to keep them separate from the views and controllers.
    – DFord
    Dec 2, 2013 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. Dec 2, 2013 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? Dec 3, 2013 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. Dec 3, 2013 at 1:12
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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