I'm about to start on a six month project to build a large social network solution (don't bother trying to tell me this is a bad idea, I"ve spent 3 months trying to connivence investors that getting users is the hard bit, and they are confident they can solve that)
I'm building the core stack with ASP.NET MVC and MSSQL Web. It's what I know, and I'm confident the business model can support the licence fees. If needed I plan to use redis/mongo as needed, but that's scaling before I need to, in regards to db read/writes.
However the service will need to handle a significant of video encoding, so I'm thinking about splitting of that functionality into another completely open source framework, that nodes can just be spun up as needed. To be fair, these nodes could probably just latch back onto the master db cluster, and I could continue to build it all in .NET MVC.
I've done a fair bit of work with django, and some PHP. How ever this all comes down to feeling like I'm missing something by not getting into ruby, and some of their deployment techniques and tools.
Aside from the fact I should learn as many things as possible, is there any reason I shouldn't build this fairly simple video handling web app in ROR? I'm imagining I'd just get it to call FFMPEG somehow, and hopefully there would be librarys to help with this. I'm already very confident with mediahandlerpro on the c# side.
Another slightly non-technical question, but I couldn't decide whether to ask here or on Server Fault...
I can't say I'm an MVC guru yet, but I've built several LOB applications so far in ASP.NET and WPF/Silverlight and am currently working on one in MVC 2, so I do know my way around for the most part. My concern is more about the accounting side of things.
It's easy to go wrong; for instance, I once got hired to fix a situation where reports on old transaction records were being calculated using new taxes. Obviously I know now to avoid that particular problem, but there's all sorts of other things as well, especially when international billing becomes involved.
There are packages like Magento and OSCommerce (the latter of which I've used with pretty good success) for PHP, but that's the thing -- they rely on the LAMP stack. Integrating it with the rest of the website could prove to be a real pain, especially if I end up having to host it on a separate Linux machine -- which I probably will. Juggling user accounts and styling and all that would be a killer.
A lot of the MVC tutorials out there are tutorials in building e-commerce sites -- which is pretty cool, but they're still just tutorials, and I doubt they cover all the issues.
Anyone have any experience in this area?
Edit: Commerce Server, at $7,000 per CPU, is out of the question for me, unfortunately.
Edit 2: Wait, it looks like Commerce Server's also available on TechNet... not sure if it's a commercial license though.
Actually, Google Checkout and Checkout by Amazon should work for me. Interestingly, they're practically identical services.
we have a mixed development environment using ASP.NET MVC and Ruby on Rails. We have come from a purely C# / ASP.NET background, but now have some rails experience and we love both. Problem is deciding at the beginning of a project which one to use can sometimes be tricky.
Any tips for how to explain to the non technical members of our company and our clients why we would chose one over the other for various projects?
Thanks in advance.
Deployment? Rails is interpreted, ASP.NET MVC requires compiling.
Speed? One's bound to be faster than the other, I'm assuming (although I cannot be certain) that ASP.NET MVC would be slightly faster as its compiled.
Platform? ASP.NET MVC obviously has to run in a Windows environment, whereas Rails could run on *nix/Windows/Mac
Development time? You're all going to be more familiar with the constructs of one system over another meaning one will take you longer to develop in. If speed of development is required, one will be preferable.
To be honest if they are non-technical, why would it matter to them? It's pretty rare for a customer to come and ask for a specific technology, and it sounds like you would be picking for them. Then presumably they would trust you to pick the appropriate technology.
If you have to justify to management, I can see that mattering, though. I have developed mostly with Rails and a little with ASP.Net and I do have a favorite, in Rails. That said, I would just fall back on my default and then just tell them the requirement that requires me to jump to the other technology. They can probably understand most reasons, like the ones illustrated by Kezzer.
Any tips for how to explain to the non
technical members of our company and
our clients why we would chose one
over the other for various projects?
If they're non-technical, I don't see why they would care.
However, you could just tell them Microsoft made ASP.NET MVC while Ruby on Rails was not made by Microsoft.
Or, for which ever one you choose, just tell them it gets the job done the fastest/easiest.
Giving them a good response would require them to be technical (performance, compiling, etc..).
Does any one know about any real application built on asp.net MVC framework. I am not
talking about opensource projects as I am pretty much aware of it.
I am more interested in knowing about any commercial website like banking, ecommerce
or any other line of business application that's built on this framework.
EDIT:
Clarification regarding opensource. I am pretty much aware of opensource projects and they are great. What I am looking for is commercial business application that's made on this framework.
If you visit What is ASP.NET MVC? and scroll to the bottom there is a list of sites that use ASP.NET MVC including stackoverflow.com.
Yes, I have built a commercial "line of business" application on ASP.NET MVC 1.0. We started development on the site when the framework was in beta; and released the site this summer. We are completely happy with our technology choice. Unfortunately I really can't say much more, as my employer would not welcome it.
I'm not sure about the OP's intent; do you mean to get validation of the MVC pattern for very large codebases, i.e. 200 kloc or larger codebases? I can't give you that, and I doubt anyone else really can right now, because there simply hasn't been time to develop so large codebases since the release of ASP.NET MVC. I would suggest researching MVC in Java, as this is probably where you'll find most older & large MVC deployments.
My usual counterargument to the 'very large codebase' fear is you simply shouldn't design so large monolithic apps anymore -- break up the responsibilities and use a SOA architecture to reduce complexity for each individual area of responsibility.
For a webapp on the .NET stack I'd select ASP.NET MVC again with complete confidence. That said, there are many other good choices in webapp frameworks these days.
In here you can easily find top 10 web sites that are built with ASP.NET.
http://www.findmyhosts.com/top-10-asp-net-mvc-framework-websites/
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. :)