ASP.NET MVC Question

RockLobster · 28 Feb 2014 at 15:53

Just started using MVC. Just wondered what the norm / best practice is with splitting the data model, etc. This is what I've done so far.

In my solution I have a MVC Project and a class library project which contains my Entity Framework model - Database First. At the moment I'm using a controller to save some data to the database: -

Code:

[HttpPost]
public ActionResult Upload(HttpPostedFileBase file)
{
//a load of code here to setup the blob class
//........
//create context
var context = new LIVEEntities();
context.BLOBS.Add(blob);
context.SaveChanges();
}

I assume this is bad practice as I've read that controller code should be kept a bare minimum. Where is the best place to do this? In the class library or somewhere else?

Gambisk · 28 Feb 2014 at 16:03

Have a browse at this http://blogs.msdn.com/b/aspnetue/archive/2010/09/17/second_2d00_post.aspx

It really depends on your overall architecture as to how much/little you can get away with in the controller. In work we have gone for a REST service so most of the time our controllers are just passing data from the view to the server or vice versa. We then have Business logic and DAL in separate projects on the server side, but this is for a large enterprise app, if I was just knocking something together for personal use I'd be tempted to buck it all in the controller for speed.

RockLobster · 28 Feb 2014 at 16:05

Hi Gambisk

Thanks for that link. It's a small project at the moment but it could become a large project. At the moment I don't have any models in my model folder which seems unusual when you see most examples on the web do.

robotSocks · 28 Feb 2014 at 16:49

you need to wrap that EF data context in a using block - it's got a handle to a database connection underneath it.

i'd recommend using a DI container such as Unity, Autofac etc. and receive the data context as a constructor argument on the controller.

davetherave2 · 28 Feb 2014 at 22:50

Personally I like to have my models in a model class as well and then they can be easy moved from one project to another if needed. Then I have my data access in a class library like you but I am planning to use a webapi project to do all the server leg work for me.

I like to go down the route of keeping the front end as light as possible and make sure any business logic can be tested simply and not have too much. The point at which a function starts to have too many conditional if statements is usually the point I start refactoring.

_syn_ · 3 Mar 2014 at 12:35

Just starting out with MVC myself been using web forms for far too long but have now seen the light. Certainly some good suggestions above. we tend to follow the N-tier architecture (i.e DAL, Business layer and UI etc.)

davetherave2 · 3 Mar 2014 at 20:50

I came from a winforms/webforms background but was indirectly using the mvc principles in my webform apps to try and make them a little easier to test.

It took me a bit of time to get my head around the razor syntax but I have found it so much easier than webforms and reskilled myself in less than 12 months.

_syn_ · 4 Mar 2014 at 10:15

I'm really enjoying it so far, so my enthusiasm is currently shielding me from the negative effects of the learning curve

. I'm certainly a control freak when it comes to coding so from that perspective being able to tightly control the mark up as well as url navigation is an absolute revelation!

RockLobster · 4 Mar 2014 at 15:24

I'm struggling at the moment. WebForms was so easy although once I get used to it I'll enjoy it more.

Stelly · 4 Mar 2014 at 15:26

RockLobster said:
I'm struggling at the moment. WebForms was so easy although once I get used to it I'll enjoy it more.

When you get the hang of it you will love razor engine dude. I'm currently enjoying using it

Stelly

davetherave2 · 4 Mar 2014 at 19:52

RockLobster said:
I'm struggling at the moment. WebForms was so easy although once I get used to it I'll enjoy it more.

It took me a while to figure out the razor engine. Once I got my head around it then it comes as second nature.

The joys of not having to fight against the page life cycle is so rewarding.

What specifically are you struggling with at the moment?

RockLobster · 4 Mar 2014 at 21:34

davetherave2 said:
It took me a while to figure out the razor engine. Once I got my head around it then it comes as second nature.

The joys of not having to fight against the page life cycle is so rewarding.

What specifically are you struggling with at the moment?

If you see my other post I can't get my head around something simple like that. Basically, a textbox where a user enters a value and that value is used as a parameter to populate the dropdownlist which is bound to a datasource (entity framework).

Dj_Jestar · 5 Mar 2014 at 09:13

robotCocks said:
you need to wrap that EF data context in a using block - it's got a handle to a database connection underneath it.

i'd recommend using a DI container such as Unity, Autofac etc. and receive the data context as a constructor argument on the controller.

Jumping straight to recommendations of containers.. wow. Talk about jumping the gun.

robotSocks · 5 Mar 2014 at 20:00

Dj_Jestar said:
Jumping straight to recommendations of containers.. wow. Talk about jumping the gun.

your input is valued and appreciated.

sist_si · 8 Mar 2014 at 01:18

hi all, I've used MVC for a few years now and I actually split my data from my View model so I can keep a really clear separation so, for example:

For example, I'll have a model called 'Article'
This (using EntityFramework) will be mapped to the database and will contain all my methods (GetAll, Get, Insert, Update, Delete etc...)

I then have a corresponding model to be used in the View side of things e.g. 'ArticleVM'
This version contains all my DataAnnotations and rules for [Required], field types, length restrictions on forms etc.

The constructor(s) for 'Article' accept 'ArticleVM' and 'Article'
The constuctor for 'ArticleVM' accepts 'Article' and this also means I can specify any related elements to be loaded (say for instance if my article has an image gallery attached to it) to be loaded when I instantiate the 'ArticleVM' object rather than everything loading all the time if it's a particularly complicated model. A simple private method in each class stops any duplication of constructor code.

Views only ever handle and post the 'VM' versions of the model and the controller simply converts them straight over to the data side of things in one line of code (using the constructors outlined above) where they are passed over to the DB.

Nowadays I actually use the 'Repository/Unit of Work' way of handling the database work so my model code is really stripped down and any model's database work can be handled via a single class. Saves even more time coding.

RockLobster · 10 Mar 2014 at 08:39

Hi sist

Your view models do you put them into the same project as your MVC stuff or a separate class library?

sist_si · 10 Mar 2014 at 13:04

All the same project. I just like the level of separation it gives me.