Search code examples
asp.net-mvclinq-to-sqlbll

Working with MVC 2.0 and the Model in a separate assembly

I'm new to MVC and even though there is a lot (and I do mean a lot) of information out there that is very useful - it's proofing very difficult to get a clear understanding on how to achieve my exact requirements with MVC 2.0.

I would like to set up a solution as follows:

  • Provide a web UI using an MVC 2.0 project.
  • Use Linq to SQL classes project for data persistence.
  • I have a two separate code modules that will need to access the above Linq to SQL model - so I won't be able to include my Linq to SQL model directly in the MVC project itself.
  • Also I have a Business Logic layer in front of my Linq to SQL project.

My questions are:

  • How do I set up the Model part of my MVC application to point to my Linq to SQL project via my BLL?
  • How do I perform web app validation? Can I use MVC 2.0 Model Validation? If not what are the alternatives?
  • Finally (and slightly aside) - What is the ViewModel and how does this differ from the Model?

So many questions. But this is an exciting new technology and data access issues aside, everything else I've got to grips with very quickly and I think MVC 2.0 is fantastic.

Thanks for any pointers you can provide.

Solution

  • How do I set up the Model part of my MVC application to point to my Linq to SQL project via my BLL?

    Typically you'd use a repository pattern for this. Your controller has a reference to your repository - the repository returns your domain objects from your database. The MVC app has no knowledge LINQ to SQL exists.

    How do I perform web app validation? Can I use MVC 2.0 Model Validation? If not what are the alternatives?

    Put view models in your MVC project. These view models may closely align with your domain models but their concern is to be the presentation model. Put your data annotations for validation on these view models - the MVC framework will automatically ensure validation occurs on these view models decorated with data annotations. It's pluggable so you could use alternatives - but with MVC 2, it's baked in fairly well and this includes client side validation.

    Finally (and slightly aside) - What is the ViewModel and how does this differ from the Model?

    I partially answered this one above. the shape of your domain models may not be the shape you need to display your views - view models are great to bridge this gap. Additionally, even if the shape does match exactly - view models are still a good idea so that you can put UI validation code there and other presentation meta-data on them (since you do not want anything related to presentation logic on your domain model).

    Here's link for view model patterns.

    Hope this helps.