Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
So, I've spent enough time using ASP.NET webforms to know that I'd almost rather go back to doing classic ASP than use them. But I'm hesitant to move to ASP.NET MVC until it becomes more mature. Are there any open source alternatives?
The main thing I'm looking for is something that's easy to learn and to get a prototype up and running with. If it's any help, my main preference is a python "mix and match" approach (like say web.py/SQLAlchemy/whatever templating engine suits my fancy at the time).
We have used MonoRail RC2 for our small business's online store for the past 18 months. It replaced a 7 year old disaster of classic ASP pages. MonoRail RC2 has worked well for us, serving an average of ~14,000 page requests per day. It enabled me to develop the site very quickly, was free, and holds up well. For that, I am thankful to the MonoRail team.
I just used the MonoRail bit. I chose iBATIS.NET over ActiveRecord as I had to write creative SQL to maintain compatibility with a 7-year-old turd of a database. So I can't speak for some of the other Castle libraries.
Some advantages of MonoRail include the following:
It's pretty easy to get in there and modify things. For example, the default routing implementation didn't preserve the query string when rerouting (I needed this to preserve backwards compatibility with the old URL formats used by the now defunct classic ASP site for SEO reasons) and it didn't support issuing HTTP 301 Permanent Redirect headers for that scenario. So I implemented whatever the MonoRail interface for that was, plugged it into my config file, and off I went.
It's still ASP.NET, so you can still use Forms Authentication, the totallly awesome HTTP/HTTPS Switcher at Codeproject, and caching.
Relatively few surprises. After working with it for over year, I haven't had too many days where I've cursed at MonoRail. That's a pretty good litmus test. Some of the helper classes (FormHelper) can behave a little strangely, the wizard framework is outright bizarre, and parameter binding can sometimes throw you for a loop, but it doesn't happen often.
Choice of View Engines (templates). I put this here because most people seem to think choice here is a good thing although I usually think that it is not.
MonoRail, however, is not without its problems:
Lack of direction in development. The number of changes between RC2 and RC3 was beyond ridiculous; a lot of protected virtual methods disappeared, a lot of helpers changed (which is a big deal when your view engine isn't statically typed), even the mechanism for unit testing controllers and views changed. For this reason, we're probably just going to stay on RC2 forever. Now that ASP.NET MVC is out, it's unclear how healthy the community behind MonoRail will stay (though ayende and hammett are as enthusiastic and active as ever).
NVelocity, the "de facto" view engine for MonoRail (at least at the time that we started development), is a promising templating language with an unhealthy implementation and maintenance outlook. (Does it work? well enough. But being a CTRL+C CTRL+V port from the Java version, don't read the source for that library because your eyes will bleed.)
NVelocity and RC2 shipped with an extremely severe threading bug where multiple users accessing the site at the same time could get served pages intended for the other. It's fixed in the latest release (which, due to the release nature of the Castle projects, is very difficult to upgrade to), and we managed to work around it. But it was a very disturbing and unexpected issue to encounter, one that would be highly unlikely to be encountered on a Microsoft framework. Caveat emptor.
MonoRail provided an excellent opportunity for us in June 2007 by giving us a way to migrate an existing site on the Microsoft stack to the .NET platform in a way that avoided WebForms (which is great for intranet sites, but not so great when you need fine-grained control of your HTML output on a public-facing Web site, in my opinion). (Fine, the real reason is I just despise the WebForms postback model.) ASP.NET MVC was not even a gleam in Microsoft's eye at that point in time.
Now that ASP.NET MVC does exist, however, and given that Microsoft is positioning it as an alternative to WebForms, I know that I personally will strongly consider it for any future project. MonoRail is a great project, it served us well, and I'm grateful to the open source community for it, but I think of it fondly as a heavily used, worn tool that is retired to a lower drawer in my workbench. Without it, ASP.NET MVC might not exist today.
Personally I have tried both ASP.NET MVC and MonoRail by CastleProject. Although I really enjoy the other CastleProject libraries, I have found that I enjoy the ASP.NET MVC implementation model better than the CastleProject MonoRail model. Now that ASP.NET MVC has released that they will be including jQuery in with the releases, I am truly excited. Ultimately, I think it depends on what other libraries you use. If you use NHibernate, ActiveRecord, and Castle Windsor then you will probably enjoy the MonoRail libraries. If you don't use any of those libraries, or prefer the Microsoft Enterprise Libraries (currently the company standard where I work) then you will probably find the ASP.NET MVC fits your needs better. With the focus on ASP.NET MVC coming from Scott Guthrie himself I doubt it will be going away any time soon. In fact, the more people using it and signing it's praises the more likely it is to become the defacto standard.
Another alternative, with which I have no experience, is ProMesh. Personally, I moving to ASP.NET MVC.
One alternative that seems interesting is MonoRail although I haven't tested it out fully.
ASP.NET MVC should start to become more accepted as being mature in rapid fashion. Now that it is beta, and supposedly nearly feature complete, the rate at which people adopt it will continue to grow, and likely more sharply. With the RTM/RTW release promised to be in the near future, now is the best time to start to adopt it so that you can hit the ground running with it.
If there are specific shortcomings that you see in ASP.NET MVC, you should definitely let Microsoft know about it. Scott Guthrie is very receptive to feedback and the MVC Contrib project is both open to suggestions and has a great collection of enhancements available through their library.
Related
One of the reasons I'm askin this is because a lot of the versus topics surrounding these two frameworks are quite old, mostly before 2008, when ASP.NET MVC was still young. As of now, I'm not quite sure how Monorail would fit a beginner like me, but given my circumstances in which I am unable to use VS 2010, and by consequence, ASP.NET MVC, Monorail seems like the best alternative to WebForms.
I know that for the most part, both frameworks achieve the same thing, but what I'm worried about are the little things that I am unaware of as of yet due to my inexperience.
So, the complete question would be, is Monorail a viable to alternative to ASP.NET MVC in a context where I can only use VS 2008?
I may get flamed for this but I would be very leery of starting a MonoRail site at this point. MonoRail was very nice at one point but at this point the community support around ASP.NET MVC is far greater. Given you say that you are a beginner I would go with ASP.NET MVC even if it needs to be version 2 for the time being. There are a huge number of tutorials for you to get started. Then when you can move to Visual Studio Next and .NET 4+ when the opportunity presents itself.
Once you get a bit of experience if you want to dig into what are no doubt interesting developments in MonoRail 3 you can always do that later.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this 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.
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:
Ask my boss if he wants me to recreate an entire business application across a completely different platform.
Tell him he can either have it more quickly now (ASP.NET), or more quickly later (ASP.NET MVC).
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.
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.
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.
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.
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.
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!
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
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).
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
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.
Just a random question. I've been in internship and then working as a software designer for almost a year now, mainly with SQL Server 2005 / 2008, and Visual Studio 2008 with ASP.Net VB / C#, web software development. We recently started a project with ASP.Net MVC, and I just don't get this stuff.
The concept of Views, Controllers, Models etc is clear. I'm still a bit confused with some of the syntax, but it doesn't seem impossible to get. My problem however, is with all the basic controls and functions you had with basic ASP.Net. Want a dropdownlist? Go browse through 15 tutorials one of which may actually work. How about a gridview with editable rows? Manually build the tables or helper classes with loads and loads of code also built from several different tutorials. What about panels or multiview indexes to easily control the visible user-interface on a page? Well, go learn another tutorial about how to do it all from scratch. Etc..
I do not argue the idea that MVC is worth it. It has to be, with so many people smarter and more experienced than I am saying so. But I've now fought with this beast for over a month and am getting increasingly frustrated at having to use hours to days of time to do the most basic tasks that were easy even when I was barely beginning with the whole programming thing almost a year ago.
So my question. Are there others out there like me? Are there perhaps nice blogs or articles opening all this up to people like myself? Is ASP.Net MVC just something that is so hardcore advanced that you NEED to have extensive experience and talent to actually master it?
Thanks for your time.
It's not for advanced developers. It is for good developers.
Most ASP.NET WebForms developers have made it somehow through years without having a slightest idea of HTML, CSS, JavaScript or HTTP. Drag and drop some control, set up some properties and here you go. It is not the way of a professional. You need to know the basics. It is only a matter of time until some situation arrives where a standard control cannot help and you need to work around the postback mechanism, viewstate etc.
I agree that it is definitely more work trying to implement an editable data grid, add persistance for controls, add some nice Ajax effects instead of relying on UpdatePanels, yes. But you really need to know this stuff if you wish to be working as web developer.
What you are experiencing is being overwhelmed at once by all those things you should have learned already but have managed to postpone thanks to very well done abstraction mechanism of WebForms. The best course of action is to start learning these things now, step by step. It will likely take you at least 6 months of intensive studies to feel more or less confident with doing stuff manually. But when you have done this, you will be looking back at your start and feeling glad you did it.
I was trying to work out what the problem was with MVC until I grasped the essential difference between the person asking the question and me - it would be this, I first laid hands to keyboard in 1979 whereas Zan has been "working as a software designer for almost a year now".
When I started one more or less had to do everything (at least in terms of presenting a UI) from scratch - or at least using far more limited toolkits than is the case today. The notion of constructing a drop down list by running a loop to create the options is in some respects considerably less alien to me than binding a datasource to a control and having the result appear as if by magic (notwithstanding 9 years of VB.OLD and over 6 years of .NET and C#)
And that is the core difference between Forms and MVC as it currently stands - the way you produce the presentation code and consequently the fact that you need to understand HTML and do seemingly more work to achieve similar results (and this is one of the reasons that people keep emphasising, quite rightly, that MVC is NOT an appropriate solution for every project). In terms of the structure of an application - MVC encourages a better (more testable) style but its not the only means to achieve that end - the majority of the techniques are as applicable using forms and alternative patterns.
And again this raises the challenge of contemporary frameworks and tools - they do a huge amount of work for you (go look at Dynamic Data for example) but they also hide so much from you that we lose track of the fundamentals and of an understanding of the basic building blocks from which our complex applications are constructed. In this case the problem sounds like one I've had which is learning about the nuts and bolts how a web page is actually constructed (HTML, CSS, Javascript) and how it interacts with the server as opposed to just having the whole client experience automagically generated for you.
MVC is no more a tool for "good developers" than Forms is - rather its a good tool for developers that wish to achieve a particular result albeit one that comes with a price just as forms is also a good tool but with different outcomes because you're accepting a different set of compromises.
A good developer is one that can adapt - can learn the new techniques necessary to work on a different platform, to target new environments, to use appropriate solutions for a particular task and ultimately that can apply solid patterns and methodologies to their work in so far as is possible whatever the dev environment...
i also spend one year on mvc what i learn till now is u can rely on client side as much as u can but in classic asp.net most of time u used server side controls like gridview. In asp.net mvc u can replace it with jquery controls like jQgrid and jquery datatable. you must have to spend some time to learn asp.net mvc the it might looks u better then asp.net classic.
for reference read asp.net mvc pro book
MVC is not a new concept; in fact other languages have this kind of framework long before Microsoft got it. Think about Ruby On Rails, Zend Framework, Symfony etc.
If you say that MVC is for the hardcore and the alpha geeks, then by your logic other language developers are much more advanced than .Net developers. I don't think this is true.
Your problem with MVC stems from your webform background; ASP.Net and ASP.NET MVC greatly differ in terms of concepts and approach. So some unfamiliarity is expected for those who are moving from one framework into another. Me, on the other hand, who has no webform experience ( although I do have winform experience), don't find MVC hard to grasp.
And I don't think I am smarter than anyone else.
All i can suggest is that you need to do more of it! The more you practise, the more it will become clear. That's how it was for me. I was fundamentally stumped by the MVC concept to start with but after much frustration i just decided i would need to force myself to start using it or i'd never get it.
I'd recommend actually completing one or two of the tutorials found on the asp.net/mvc site from start to finish. I can personally recommend the NerdDinner (and the book from which this example was birthed - Pro ASP.NET MVC 1.0) and Storefront tutorials.
ASP.NET MVC is built on top of bunch of old concepts - HTTP, HTML, CSS, JavaScript. And so on. The whole point is to bring their power directly to your hands. If you can't handle this power - for example, you're not familiar with HTTP statelesness, or how to build rich pages with HTML/CSS/JS - you can't do much with ASP.NET MVC.
If you say that you're in programming for only one year then you're most probably not familiar with those concepts and that's the problem, not in the MVC itself.
Maybe you take ASP.NET MVC as a refinement of ASP.NET. That's wrong. They're VERY different. Imagine yourself doing web development with only HTML, CSS, and jQuery [1]... can you? If you can't then you will have troubles doing MVC.
I personally worked with ASP.NET for couple of years, and ASP.NET MVC was a breath of fresh air. It's just so much simpler and cleaner.
[1] This can be done, for example with data fed via web services.
MVC is great but the argument that it makes you happy by finally giving you the power of HTML, CSS and Javascript is real crap. The same logic would say: code in pure SQL and forget nHibernate or Linq. Why is abstraction bad? I like MVC but please don't use such arguments. MVC needs something to be able to build complex rich user interfaces (which are browser compatible).
Finally, on HTML, CSS and Javascript. The fact that MVC forces you to go back to the basics does in now way mean that the developers do it right. Whether you use web forms or MVC, a bad JS developer stays a bad JS developer (and same for HTML or CSS).
Sometimes it is better to not give too much power to the weaker developers in a team.
Before I get pointed to one of those 'VS.' questions like below...
ASP.NET webforms + ASP.NET Ajax versus ASP.NET MVC and Ajax framework freedom
Should I pursue ASP.NET WebForms or ASP.NET MVC
ASP.NET MVC Web application vs ASP.NET Web Application
... please let me state that I'm not looking for a comparison.
Some of my concerns that I need answers for include:
Is the learning curve for doing crazy UIs (e.g. having UI for building a BOM tree online) steep? Lots of people posting questions seem to be having problems with some UI requirement or another which has me worried. Is the technology mature enough to handle those type of requirements?
Is there a pretty well developed community and how available is online literature? You can get tons of literature for WebForms.
Would the time to develop it be comparable or less to building a traditional enterprise WebForms site?
How long would it take to get a whole team of developers comfortable (if not enamored) with WebForms to become well versed in ASP.NET MVC?
The truth of it I think is that StackOverflow is Google-like product and ASP.NET MVC might be great for that. But I'm stuck developing software in the Your company's app category.
alt text http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png
So taking a plunge could prove very costly later on if something can't be done or it has to be hacked. Hope to hear from those that have taken the plunge.
Thanks.
About 3 months ago, I was told that I needed to develop an enterprise web-app (well, a series of small web-apps actually), but that I could choose whatever technology I wanted.
Since I'm most comfortable with VS/C#/.Net, the dilemma was whether to choose ASP.NET WebForms or ASP.NET MVC2 -- Unlike you, my only background was with Windows Forms (WinForms) and a little WPF. So I had to research (and try-out) both WebForms and MVC.
Just like you, I realized that my app would be neither Google nor Apple like, but your bog standard company app with thousands of buttons and boxes, etc. WebForms seemed like it would be the fastest to deploy, but hard to test and hard to maintain on a long-term basis. MVC seemed to have a much steeper learning curve, but once established, testing and maintenance would be a breeze.
I only fiddled with WebForms for a week, so I can't really comment on it. But MVC is definitely everything I was expecting it to be.
Yes, it's a steep learning curve. Concepts that were new to me:
Model-View-Controller (MVC)
Separation of Concerns (SoC)
Model Binding
Unit Testing and Test Driven Design (TDD)
Mocking and Stubbing
Dependency Injection (DI)
The books that helped me the most were:
Pro ASP.NET MVC2 by Sanderson (MVC, Model Binding, DI, TDD)
The Art of Unit Testing by Osherove (TDD, Mocking, Stubbing, DI)
I also had to brush up on my HTML, CSS, and Javascript.
Overall, there seems to be a fair amount of ramp-up work in the beginning, but maintaining and extending the existing application has been pretty painless. Whenever I've been asked to make changes, it's been fairly easy and I've typically been able to deliver on-time or even sometimes ahead of schedule.
In an ideal world, writing an MVC app would happen with 2 people. One person writing the core code and a second person writing the UI and the Views (HTML, CSS, Javascript.) Although it's entirely possible to do it all by yourself. (which is what I'm doing right now...)
I have run into some hitches deploying in the Enterprise, though. Internally, my company is running Windows Server 2003 and IIS6. Unfortunately, we have been unable to get the app to deploy properly on IIS6 when using Virtual Pathing. (All the references to and in the CSS files are broken.) If you plan on deploying MVC, I would recommend using IIS7 or higher. MVC supposedly works on IIS6, but requires that your IT department be willing to figure out how to get it to work.
Edit: I just realized I never directly answered your questions. Here goes:
My personal experience has said, that, yes, the learning curve is steep for building good Models and UIs, but I'm not really a web-developer so I've been working with that handicap. The good news is that the MVC technology is pretty mature.
Yes, the community is pretty well developed and growing. You'll get a lot of good answers from StackOverflow as well as MS's ASP.NET MVC sub-forum.
I have no personal experience coding WebForms, but I have coded plenty of WinForms apps and I feel like it's taken me approx. 3 times longer to build this MVC app. The initial investment is a bear, but regular maintenance and improvements seem to come WAY faster, especially as the app has grown... Since you seem to have a team of programmers, it may come faster for you guys as you can probably split up the learning/workload.
Again, no prior experience with WebForms, but what I can tell you is that as I was learning ASP.NET MVC, there were times when I was struggling to understand what was going on because I had no prior ASP.NET background. (Example: Membership and Role Providers -- I had to code my own recently. Boy was that fun...) On the plus side, I didn't have any "old ways of doing things" (aka. WebForms) to unlearn either. If you have a team of folks enamored with PostBack / CodeBehind, you can bet that MVC is gonna seem awfully strange at first. But hopefully your team will see the advantages that MVC brings and embraces it fully.
Oh, and it should be noted that you can blend MVC and WebForms. It's not an all-or-nothing proposition. Although, if I were in your shoes, I'd try to embrace MVC as much as possible and only use WebForms where it clearly makes more sense.
Ok, I hope this helps... :-)
I can answer half of your question. I've just dove into MVC from a WebForms background. There is (obviously) a learning curve, but it's really not very steep. I've been able to make the transition with little effort, and I find the whole thing to be a breath of fresh air.
However, I am quite capable with front-end technologies (HTML & Javascript), and I don't like the HTML the WebForms and Microsoft ajax framework generates. If you and/or your team are like this, you will love it. However, if you are proud of the in-depth knowledge you have of the event hierarchy, or if you love the simplicity of UpdatePanels, then you'll probably bridle against the changes.
The documentation is OK, enough to get going happily, anyway. Here's a few videos to whet your appetite:
http://videos.visitmix.com/MIX09/T49F
http://videos.visitmix.com/MIX09/T50F
http://videos.visitmix.com/MIX09/T44F
Here's your documentation home:
http://www.asp.net/mvc/
For a bit more info, the first chapter of the asp.net mvc 1.0 book is online and can be downloaded for free. See ScottGu's blog here:
http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx
And, the full code for the chapter can be found here:
http://www.codeplex.com/nerddinner
Finally, in terms of development time, I think it might take a bit longer to develop apps using MVC (although I have no evidence of this), but I think supporting, maintaining, bugfixing and enhancing will take a lot less time. So, with a small up-front investment, I think you'll more than recoup that effort.
Anyway, like I said, these are my preliminary findings. I still have yet to hit a really hairy problem.
As you know its all about the people first, technology 2nd. You can simply build out a new functionality of your company app because they can co-exist, then you can answer all those questions yourself.
It's new stuff so it will of course take more time than what you're used to but heck its all fun so jump right in and start answering these questions for your own people and app.
Interesting that your question focused all on your concerns and not on any benefits. Have you asked yourself the "why" question? If you feel you can be successful with WebForms, why change to MVC? What is there in MVC that justifies the risks? If you were paying for the project, what would you do?
I'm not pitching WebForms over MVC by any means, but as an architect, you need to be able to come back very strong to the question of why you decided to go away from a very well-known quantity to a relatively new one. I think that there are many good reasons to do so, but it not my job on the line. :)
Starting a new project and would like to use one of the MVC framworks. ASP.NET MVC is still in preview but Spring.net is in production and has a history with Java. I'd like to know the general lowdown between the two.
Current questions..
What are the major feature differences?
What about deployment/hosting issues?
Future support? Do you think Spring.net will fade once ASP.NET MVC is in production.
Current Support? I saw the Jeff twitting about a breaking change in the next preview.
Thanks!
I am a little confused by the question. Spring.Net is a dependency injection framework that you can use in ASP.NET MVC. I kind of based my answer off what you are actually asking though. The difference between ASP.NET MVC and another MVC framework that runs in ASP.NET.
If you are worried about using ASP.NET MVC in production since it is not even in beta yet, then you may want to check out MonoRail as an alternate. There are some differences in features, but the two are pretty close in terminology and how MVC is implemented. To learn differences, here is a question that was posted, that you might want to monitor. I think once ASP.NET hits release, that most Microsoft shops will switch to it. With ASP.NET MVC still being developed, you will run into breaking changes that you will have to change when you upgrade to the next release. That goes with the territory of living on the edge. You just need to read the release notes before jumping to the latest release.
I have an impression that Spring.NET never really took off, or at least not as much as Castle Project Monorail.
From what I understand, Spring.NET has also departed from Java Spring's implementation, so there will a steeper than expected learning curve if you are coming from Java. From Spring.NET's overview:
The design of Spring.NET is based on
the Java version of the Spring
Framework, which has shown real-world
benefits and is used in thousands of
enterprise applications world wide.
Spring .NET is not a quick port from
the Java version, but rather a
'spiritual port' based on following
proven architectural and design
patterns in that are not tied to a
particular platform.
As for your other questions, the breadth of the topics make them a bit difficult to answer in one go, but I am hoping Phil Haack will see this question and respond. :)
Yes Spring.net adds enterprise solutions to Microsoft's codebase, Spring will fill the crucial missing gaps.
I can attempt to answer your question on future support of Spring.net & ASP.net MVC. Apparently Spring will be releasing a new Milestone build when Microsoft go RTM/Final build:
http://forum.springframework.net/showthread.php?p=14031#post14031 (Mark is the Spring.net lead and a Microsoft MVP)
I've heard they don't want to give anything away until then, as they've had enough of Microsoft taking Springs ideas with no recognition.
Current Support for Spring.net & Controller Dependency Injection can be found in MVCContrib