Has anyone every used MVC ASP.NET?

[Frinavale]

Has anyone every used MVC ASP.NET?

I'm thinking of giving it a go and was wondering if anyone has any experience/comments on it?

[r035198x]

I would suggest making this top priority. MVC is almost the only way to create applications these days.
Basically you create classes for your database objects(the model). These classes should not have any bearing on how the database data is going to be presented to the user. They should be usable by anyone whether they are accessing the database data from a web application, desktop application, mobile application, anything. The model is your observable that others (observers) observe and react according to the changes to your model. A common pattern to look up for the model is the DAO pattern (Also make a note to read up on Factory and Abstract Factory patterns while you are at this).


Then you create your controller which contains the application logic. This is where you code the system requirements/specifications. This one knows about the model and contains code that manipulates the model but it produces generic data with no bearing as to how that data is going to be presented to the user. The patterns to use here depend on your specs.
The View(s) is/are contain the presentation and are the web pages or forms or mobile phone interfaces that display the data contained in the model. The view should not try to do any control logic (that's the controller's job) and certainly should not contain any SQL.

[Frinavale]

I've started researching MVC last night and plan on continuing with it.

I was looking for something that didn't depend on how it was being driven through the UI and thought that web services were the way to go. (My application is being developed for web pages, mobile apps, and desktop application)

I was really happy to discover MVC.

I think it's going to fit my application very well and I probably wont go back to developing typical web form applications unless I'm forced to.

I wish I knew about it sooner (like 2 years sooner) because it's so clean. Everything's separated into proper application layers: you have the UI, you have the business logic, you have the data layer. Not only is it clean but it's easy to maintain and much easier to test (because everything should work without depending on the other layers).

I'm excited about it and think everyone developing applications should check it out!

[JosAH]

What I don't like about the classic MVC pattern is described in here. When you look at the picture at the top right of that article you see that a View has direct access to the Model. The model doesn't know anything about the View though (as it should be).

I always make the view just communicate with the Controller and the Controller knows about the model. This may seem to be a detour but it completely decouples the View from the Model so the 'triangle' boils down to M <---> C <---> V

The Controller acts as a 'proxy' for the Model and models can be replaced at will, while the View can stay the same. (so point 4) of that article goes away). In my experience you get a bit cleaner code then.

kind regards,

Jos

[tlhintoq]

I'm excited about it and think everyone developing applications should check it out!

Does it do anything for those pesky little applications that aren't based on databases?

[JosAH]

@tlhintoq
Sure, most, if not all applications have some form of a model; the model doesn't need to be a database management system.

kind regards,

Jos

[gits]

@JosAH
that's what i usally do too ... exactly for the same reason that the resulting decoupled code is much cleaner and much easier to maintain and reuse ... but i wouldn't say that every application has to follow this pattern ... we have a lot of smaller apps that are just 'maintainance-apps' for database tables ... sometimes single tables, sometimes some tables are joined ... and for such simple things i just don't like the kind of 'overhead' that could be created for an app that just would have 200 or even 400 loc ... just by seperating everything according to a pattern and wrap it into view-, controller- and model-classes ... the overhead often goes for loc and development time. on the other hand sometimes i've to admit to have better done so ... for example i would have a reusable model for applications then that deal with the same data and i wouldn't have to create one later on when i would need one and then i have to do so ... but then i miss the time to refactor the old plain webapp ... so i have a model but the mentioned miniapp doesn't use it :) ... so as you could see ... i loose a bit with the 'overhead'-argument ... but in my case its a matter of importance that the development time has ... we've got a quite nice framework that allows us to quickly write such miniapps without a MVC-pattern ... and it's very easy to use it ... but as i said ... sometimes the decision to use it has a drawback when there is a chance that the 'model' could be reused ... and then i would have better done to follow the pattern :) ...

kind regards

[Markus]

After switching to MVC on top of some of the PHP frameworks, I wondered 'how the hell was I working like this (without MVC)?' Not sure what it is like in ASP.NET, but the benefits of MVC are great regardless of language, I assume.

[Atli]

@JosAH
This always made the most sense to me to.
Detaching the View from the Model makes the code easier to manage.

I've been using MVC for a long time in PHP, but I've never imagined using it in ASP.Net.
I mean, Visual Studio does everything it can to push you into a procedural style of coding. It would probably be a major pain to try to code MVC applications in it...

... he said, 15 days later :P
It's getting to quite around here!