MVC 4
- Thread starter Thrash
- Start date
Associate
Not necessarily MVC 4, but I recommend MVC Music Store, depending on which tutorial you're referring too.
Soldato
Again not specifically MVC4, but Nerd Dinner is also a good one.
Soldato
Set yourself a project?
I made a simple 'Intranet' side for work which helped me learn some MVC3.
I made a simple 'Intranet' side for work which helped me learn some MVC3.
The tutorials on Asp.Net are quite good. What specifically are you looking for that these lack?
http://www.asp.net/mvc/tutorials/mvc-4
http://www.asp.net/mvc/tutorials/mvc-4
I need to skill up with MVC 4 very quickly (over the weekend), so looking to run through as many tutorials as I can, just to get a better feel for it. Already been on a one day intro to it and have plenty of experience elsewhere including .net but more on the desktop application side. I have inherited a project out of the blue so want to hit the ground running.
I found the asp.net tutorials ok but a bit limited.
Thanks for the suggestions.
I found the asp.net tutorials ok but a bit limited.
Thanks for the suggestions.
Soldato
To be honest if you already have .Net experience it shouldn't take you more than a couple of days to pick up MVC - it's really straightforward.
Once you've got the idea of Controllers, Models and Actions all that's really left is to get a handle on PartialViews and how they help DRY up code and returning Json for AJAX calls if required.
As far as best practices go, the basic ones are keep as much logic as possible in the Model (avoid the Fat Controller) and none at all in the View. Also, try to keep your routes as simple as possible, otherwise it'll become a nightmare you don't want to be having.
If you've only done desktop stuff you may also want to look at the MembershipProvider if you've got a secure login site.
What ERM are you using? If it's Entity Framework be aware that it doesn't scale very well.
Once you've got the idea of Controllers, Models and Actions all that's really left is to get a handle on PartialViews and how they help DRY up code and returning Json for AJAX calls if required.
As far as best practices go, the basic ones are keep as much logic as possible in the Model (avoid the Fat Controller) and none at all in the View. Also, try to keep your routes as simple as possible, otherwise it'll become a nightmare you don't want to be having.
If you've only done desktop stuff you may also want to look at the MembershipProvider if you've got a secure login site.
What ERM are you using? If it's Entity Framework be aware that it doesn't scale very well.
Gone through the Mvc Music Store tutorial and it is pretty good once into it, I'm starting to get a hang of how it hangs together. The project is straight forward and if I was going native in iOS for instance, it wouldn't phase me. However, they have started down the route of a web app, so that's what I've inherited, at least for the time being.
I don't know what ERM if any has been used so far, will find out tomorrow. Will be meeting the SME tomorrow as well so I should have a better handle on the requirements and what still needs to be done then. Oh the joys.
I don't know what ERM if any has been used so far, will find out tomorrow. Will be meeting the SME tomorrow as well so I should have a better handle on the requirements and what still needs to be done then. Oh the joys.
Soldato
Sorry yes, ORM.
We used it on a project at work. It worked fantastically well on the dev system, no speed concerns whatsoever. However when the first system went live after loading with data (about 10Gb spread accross ~40 tables, with several tables holding 2m+ rows) we noticed it immediately started to slow down. We ended up de-normalising some high traffic/low performance tables, but even then it wasn't great.
Come a month later when we had added another 4 clients worth of data the CEO was ready to lynch the entire dev team. We ended up writing our own data layer with a completely normalised DB and dumping EF. This is still running well on a 30+ client system with ~200Gb of data.
I've tried to google about the issue, but this article is about as close to the topic as I could find.
We used it on a project at work. It worked fantastically well on the dev system, no speed concerns whatsoever. However when the first system went live after loading with data (about 10Gb spread accross ~40 tables, with several tables holding 2m+ rows) we noticed it immediately started to slow down. We ended up de-normalising some high traffic/low performance tables, but even then it wasn't great.
Come a month later when we had added another 4 clients worth of data the CEO was ready to lynch the entire dev team. We ended up writing our own data layer with a completely normalised DB and dumping EF. This is still running well on a 30+ client system with ~200Gb of data.
I've tried to google about the issue, but this article is about as close to the topic as I could find.
Last edited:
You sure EF was actually the culprit there though as that dataset doesn't sound particularly large, I've worked on a few EF projects with hideously complex schemas and monster data sets and they've always worked as expected once in production. I tend to favour database first rather than code first though so we can get a properly optimised db, views and procs in place and use these rather than trusting any ORM to be able to generate db objects itself.
Seems to be the fashion these days is firmly going towards code first though but I'm old school in that I don't like something deciding a schema for me.
Caporegime
If you have to understand what something is doing on your behalf in order to stop it being rubbish, it's a failure. 
I don't like EF either, and there is a large number of people out there who also don't like it, just as there are a large number of people who do. Managing mappings has always been a bit cumbersome, in my opinion. I also don't particularly like the restrictions of class == table. These may have been alleviated since I last used it though, I don't know and frankly don't care The feel of the ethos, I guess, doesn't feel right to me. Dapper for quick stuff, NHibernate for the complex stuff 
I don't like EF either, and there is a large number of people out there who also don't like it, just as there are a large number of people who do. Managing mappings has always been a bit cumbersome, in my opinion. I also don't particularly like the restrictions of class == table. These may have been alleviated since I last used it though, I don't know and frankly don't care
The feel of the ethos, I guess, doesn't feel right to me. Dapper for quick stuff, NHibernate for the complex stuff
Last edited: