How can I do rapid application development with ASP.NET MVC? [closed]

Question

I've been given a short amount of time (~80 hours to start with) to replace an existing Access database with a full-blown SQL + Web system, and I'm enumerating my options. I would like to use ASP.NET MVC, but I'm unsure of how to use it effectively with my short timetable.

For the database backend I'll be using Linq to SQL as it's a product I already know and can get something working with it quickly.

Does anyone have any experience with using ASP.NET MVC in this way and can share some insight?

Edit: The reason I've been interested in ASP.NET MVC is because I know (100% confirmed) that there will be more work to do after this first round, and I'd like my maintenance work to be as easy as possible. In my experience Webforms applications tend to break down over repeated maintenance, despite discipline.

Maybe there's a middle ground? How difficult would it to be for me to, say, build the app with Webforms, then migrate it to MVC later when I have more time budgeted to the project?

Edit 2: Further background: the Access application I'm replacing is used in some capacity by everyone in the building, and since it was upgraded from Access 98 to 2003 it's been crashing daily, causing hours of lost productivity as people have to re-enter data since the last backup. This is the reason for the short amount of time - this is a critical business function, and they can't afford to keep re-entering data on a daily basis.

Chatham

What do you want to know? If you have a short time, learning a new framework and method of doing things is not going to be a good idea! – Fulsome

It's going to take you longer than you think; but with ASP.NET MVC you can be up and running rather quickly -- if you know ASP.NET MVC. However, none of the things outside of the data layer transfers. You're going to have to come up with a new UI and Controller logic. RAD doesn't help you here; it's a whole new paradigm. – Morelli

I think once you've got enough code in place, using ASP.NET MVC can become very RAD like. – Yajairayajurveda

@Erik: Building it with Webforms and rebuilding it with MVC later will never happen. Quite simply, it'll be a complete re-write. The paradigms are just too different. There will be very little you could re-use. – Morelli

@Geo +1, but it all depends on how tightly linked your code and the UI is linked. If you keep your codebehind as slim as possible and keep your logic as ignorant of the UI as possible you can reuse a significant portion of it. But it definitely is a very different paradigm and you will definitely have issues if you rely heavily on the codebehind. – Christy

@Will I'm thinking about those that use the <asp: /> controls; none of those can be reused without getting close to breaking the separation of concerns with view and controller (and in most cases, breaking it). Heck, even with the <asp:ListView> you break the separation between view and Controller; and that's arguably the least 'Webforms' table control there is. – Morelli

Answer 1

There really are no good answers.

I'd be very surprised if you could recreate a non-trivial business application in a new format (web) in any 'short' amount of time (unless you measure 'short' to be 6 months).

ASP.NET MVC provides (hands down) the most convention available with any beginning web project.

ASP.NET lets you drag-and-drop to get things working, but it breaks maintenance horribly for non-trivial applications.

If it were me, I'd do three things:

1. Ask my boss if he wants me to recreate an entire business application across a completely different platform.

2. Tell him he can either have it more quickly now (ASP.NET), or more quickly later (ASP.NET MVC).

3. Let him make the call.

---

Personal Addendum: I've used both ASP.NET and ASP.NET MVC for web applications. MVC is just better. Not faster, but better. It made web development 'fun' again for me.

Morelli

This is what I'm going to do - I've explained the situation to him, explained the tradeoffs involved between the conflicting goals (speed of development vs cost of maintenance) and asked him for his recommendation. – Chatham

Also - I've been given 80 hours for now. Not a lot of time. =X – Chatham

@Erik : I don't like to speak in absolutes, but unless this is an insanely trivial application, I'm not sure you could ever do it in 80 hours. – Morelli

It's not, and I don't think so either. Tomorrow I'm going to email my boss and tell him I'm going to need more time. – Chatham

Answer 2

MVC isn't really a RAD development framework.

You'll be writing much more infrastructure code than the RAD Webforms alternative of dragging a datagrid and a datasource onto a .aspx page. I love MVC but if you're under the gun go with Webforms. MVC can be faster, but only if you have infrastructure pre-built.

MVC 2 alleviates some of this by including Model based HTML helpers like Model.EditorFor() but it's not good enough yet. No quick grid code. Paging? You're rolling your own pager. Ajax? Write your own JQuery.

Sure, there are 3rd party and open source libraries available for all this stuff but in my experience smushing them all together and making sure they play nice is also time consuming.

Coulson

ASP.NET MVC provides the infrastructure (see: Convention over configuration). With Drag & drop Linq-To-SQL, you already have half the model done. The infrastructure is there -- but you do have to be competent in understanding MVC, and you can't just rely on drag and drop controls that take the programming out of programming. – Morelli

Lol, MVC provides the infrastructure, look at this Linq to Sql feature? And anyway, we are not talking about why drag and drop is bad, we are talking about if drag and drop is faster. – Coulson

Edited my question with some more background. – Chatham

Answer 3

Simple web application + tight schedule = ASP.NET webforms.

Complex web application + tight schedule = ASP.NET MVC.

I've found that as the complexity of a web app increases linearly the complexity of a webforms app increases exponentially. Once you start writing your own server controls (NOT user controls, as those are still relatively simple), which can be necessary for more complex UI, you need to have an intimate knowledge of the whole page lifecycle, how the viewstate works, and other obscure parts of webforms that the framework abstracts from you.

MVC, while it requires you know HTML well, does great on the tail end of complexity. No matter how complex the application is, you're still dealing with POCOs and methods in your controller. Once you get over the initial hurdles, its smooth sailing. Development difficulty increases at the same pace as website difficulty.

Personal experience: I converted a relatively complex website using custom server controls to ASP.NET MVC and cut the codebase in half. I also drastically reduced the complexity of the code as well.

The only caveat I have is that ajax is easier to do using ASP.NET AJAX. So if you're going to develop a web app that relies heavily on ajax then webforms may just beat MVC.

---

Migrating from ASP.NET to MVC isn't always the easiest. You have to move from a codebehind-based application to one where your controllers are unaware of your UI. Also, MVC relies heavily on the URL to determine the intent of the user, whereas ASP.NET relies on event handlers.

Personally, if I felt an application was destined to be MVC, I wouldn't waste time developing it in ASP.NET. But then, I've had the benefit of getting past the initial learning curve. Which wasn't all that bad IMHO. I had more trouble learning all the HTML and HTML forms that ASP.NET kept me from learning.

Christy

Edited my question with some more background. – Chatham

Answer 4

With this deadline i think it's more convenient to use the ASP.Net Webform. After this first phase with more time/budget you can start to develop new parts of your application using the MVC since they can coexist.

Also be aware of the Ajax and grid code. In MVC they usually take longer to develop but also at least for me they appear to be more robust because you really have to know what you're doing.

This question is from 2009, would be nice if the author give some feedback of his decision.

EDIT: Take a look into http://mvcscaffolding.codeplex.com/ if you still need a RAD using asp.net MVC.

Contrast

It ended up not being my decision. I left the company before they began their conversion, and they did indeed go with ASP.NET MVC. Thanks =) – Chatham

Answer 5

Once you get running with MVC, it's pretty quick, but it takes a while a) to learn and b) to build up a suite of useful bits of code.

If your UI is not going to be complicated, it can be very easy to set up a quick data entry interface.

If your UI is to be really, really simple, you might like to look at ASP.net dynamic data.

Impuissant

Answer 6

You can also look the Entity Framework to bind to your database, this will create your models to be used with MVC. But Like jfar said, under short deathline pressure, go for what you know best!

Artist

Answer 7

ASP.Net MVC is good, but ....

If you haven't developed a system using ASP.Net MVC before, then using it on a project with a short deadline is a risk.

If your application is a "simple" CRUD application then I would go with Dynamic Data: http://www.asp.net/dynamicdata/ (Paddy just beat me to that one)

If your system is really big you could consider SharePoint Access Services http://blogs.msdn.com/access/archive/2009/10/21/net-developer-blogs-about-access-2010.aspx

Bodycheck

Answer 8

Evolutionary Software Development

From experience I vouch for it - it's how I program, it works regardless of technology.

In short: do what your gut-feel tells you (code something), modify as you find errors/omissions, and when it works, you're done (but for the documentation).

Radbun

Answer 9

Another option is to use Alpha Five v10 -- It recently received a thumbs up from Infoworld check out http://blog.alphasoftware.com/search/label/Press%20coverage

Distich

Take a look at [AppEnd][1]; an opensource and freeware low-code RAD platform [1]: github.com/mirshahreza/AppEnd – Arius

Answer 10

Both frameworks contribute enough in delivering a solution, but WebForms automate some of tasks involved in UI functionality, like data paging, sorting, state persistence or custom data persistence and more, BUT... if you really sit down and say, ok what do i need to do? ... design, navigate, modelize, present and then figure out how to show layout, how to connect to data, how to bring data, how to bind them with UI, how to paginate, sort and finally edit, really put your mind down and compare techinques in each framework that accomplishes all that, you will know that MVC is more natural and team oriented. You need tools like EF Code First, a CSS framework like Bootstrap and jQuery, apply techniques like IoC, SoC, Layering etc and use for example Automapper for doing the boring stuf, but no matter how many things you will have to consider, it will always be match more easy, natural and direct than having to know all the various configuration of the numerous controls and managers that WebForms require. Except if your project is an ERP with CMS capabilities where ... you know :-) Anyway, modern skils require to adapt in today's trends and MVC is just a good host to help you use them without suprises. I ve written tons of WebForms code but i am not touching it again. So, final point is that in 2014 with all those tools and frameworks out there, MVC is not slower but rather the opposite, but requires an initial, small to me, efford to gather some resources and lock a few methodologies.

Kantianism