I am hoping this doesn't get flagged as subjective since everyone's idea of "good" can be different. However, I know that you know what I mean, so, instead of flagging this question, feel free to edit the subject if you think it could be presented in a more objective manner. This is also not a duplicate of a good tutorial for .Net development with MVC, spring.net and NHibernate.
I come from WebForms and need to learn MVC. I came upon this tutorial on MSDN which has been great for understanding the basics of the MVC design pattern. However, it's just enough to teach someone the bare minimum so that they have everything they need to know to build a rudimentary ASP.NET MVC application. From what I've seen, the methods illustrated there aren't exactly what I'd put in a professional, enterprise solution which is exactly what I am about to start working on. I'd like to jump straight from the basics to advanced development, so I am interested in a tutorial/guide that has achieved popularity for being a solid resource for MVC development and best practices.
I realize that this question could have multiple answers, only one of which can be selected. However, there's still the upvote system, so answerers can still get points and the upvotes will still serve as indicators for helpful answers which is really what SE is all about.
I think a good starting point, it would be to check the www.asp.net site. it's certainly a good place to start. There would you find many tutorials for your purpose.
Furthermore, if you are about to buy a book, check PRO ASP.NET MVC 4 by Adam Freeman, http://www.amazon.com/Pro-ASP-NET-MVC-Adam-Freeman/dp/1430242361/ref=sr_1_1?ie=UTF8&qid=1387461608&sr=8-1&keywords=Pro+ASP.NET+MVC.
It's really a masterpiece.
It's been a while since I've looked at it, but NerdDinner helped me out when I was getting started -
http://nerddinner.codeplex.com/
http://nerddinner.com/
I'd like to jump straight from the basics to advanced development, so I am interested in a tutorial/guide that has achieved popularity for being a solid resource for MVC development and best practices.
In my opinion, using a framework in enterprise level requires deep knowledge of every part of it. why a component/class is designed, what is the purpose of it, how do we use it, what's the best practice, etc.
In this way I have found the Programming Microsoft ASP.NET MVC by Dino Esposito very helpful. The book's aim is to explain the mechanics of the framework and effective ways to use it.
Related
I'm quite a proficient ASP.Net Web Forms developer, but I would like to get some exposure to MVC to see what it's like and if there are benefits to using it.
Is it worth using MVC for a hobby project, my main concerns are:
It may hinder development times of the website
I may not appreciate any rewards for using MVC (i.e. testability)
Are my concerns reasonable?
Thanks
A hobby project may in fact be a perfect introduction to MVC if you want to learn it. I thoroughly recommend having a play. If you haven't used MVC before I wouldn't attempt it for a large scale project, smaller projects like you may be undertaking are great stepping stones for learning the new framework.
Of course, you've got to weigh up hindrance against progress. The time taken may hinder this project, but in the long term, getting an introductory exposure now has got to out weigh that?
I started a hobby-project earlier this year in ASP.NET MVC (later upgraded to MVC2), and it's the single best learning experience I've had the last few years.
So my answer is a definite 'YES'
Do it, and try to exploit as much of the features in MVC2 as possible. Strive to do things as simple and reusable as humanly (or maybe technically) possible, and you'll be a master in MVC2 in no time :D
Why not?
You say it's a pet project, so time is not really an issue. Given a good book, or based on the examples on the ASP.NET site, you should be able to get up to speed fairly quickly.
Testability is one of the strong points for ASP.NET MVC, so maybe you should try writing tests and decoupling your views from business logic? Who knows, you may like it. Either way, doing so will allow you to claim personal experience of using a new technology on your CV, plus learning something new is always fun.
You'll learn from it and can then take it into a work situation. And besides that, it's nicer to work with than web forms...
I certainly wouldn't want my first venture into a new technology to be a live project so I'd certainly recommend starting a hobby project.
Throughout your first development in ASP.NET MVC you will probably make architectural mistakes whilst you get used to the MVC pattern. You will also find yourself without much of the WebForms functionality and will need to think about how best to apply your design to the technology.
Essentially, you'll learn whether it is worth using it or not throughout the project. A decent rule-of-thumb is that any project that will take you more than a couple of months development time will probably be better developed with MVC.
Just to add to the above, I too would recommend you play with MVC. I've found that I'm actually more productive in MVC than in Web Forms.
In case you have not found this tutorial, highly recommended as a beginners guide and written by Scott Guthrie:
Html Version
PDF Version
I’m new to asp.net and the mvc framework and I’m trying to learn by using the asp.net learn tutorials for Building a Contact Management Application in vb (http://www.asp.net/learn/mvc/tutorial-29-vb.aspx).
The question I have is that I would like to begin a new project to start using mvc, but how do I start….
The tutorials start by putting data access and logic into controllers at first and then making the application loosely coupled by refactoring the code.
Is this the way to approach a new project or should I be making the application loosely coupled from the start?
I have followed the next iterations of the tutorials about TDD but couldn’t get my head around that just yet and wanted to really focus on cementing what I’ve picked up so far.
Any help or advice would be great.
I would probably check out the NerdDinner sample app and eBook. It provides some pretty good direction on the best way to do things. Link Here
Id recommend jumping straight into the sharp architecture stuff.
http://www.sharparchitecture.net/
Rob Conery has a good series of walkthroughs in regards to creating an asp.net mvc storefront application. I think they include TD stuff, but are done in C#. Here is the link.
I don't mean to scare you but I wasn't really productive until my 4th project.
Sure, I managed to hack out a few sites but if anyone looked at the code I wouldn't own up to it! :)
Nerd Dinner is certainly the place to start. I also found this site to be one of the most useful.
The trick I found was to, once Nerd Dinner was out the way, pick a pet project and get into it. Then, I picked another pet project and corrected the mistakes I made in the previous one. The 4th project actually resembled a well written site.
It's just because the paradigm for writing sites in mvc is so different that there is a pretty big learning curve. At least that's been our experiance here.
I also recommend S#arp all the time. I was novice to IoC, NHibernate, and MVC when I started, and S#arp was a big help. As for VB, S#arp can be used as binary assemblies; however this surely won't be as easy.
For VB/C# look here: https://stackoverflow.com/questions/1653895/should-i-learn-vb-net-or-c. I personally rarely answer VB questions, and I find C# lambda very helpful, so I can confirm many points there.
But if you only need to learn MVC, not to start real project, NerdDinner will do. Just don't take it as real-world best practices; it's to teach MVC stuff/features, not how to write well-designed and maintenable programs.
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 4 years ago.
Improve this question
update: I know there is no one best way to do everything. Sorry for not saying that right off. In the context of the data-access tutorials, if you had to do the project he did in that tutorial, would you do what he did or would use use MVC, if you had to choose one of them?
Update: Is MVC the more appropriate way to program asp.net applications, instead of the tutorials found here:
http://www.asp.net/Learn/data-access/
Original:
I ask, because I initially learned about MVC with Java applications, then things like RoR, and Django. These other projects and companies spoke as if MVC had been around for a very long time, and from what I found out it had. Then Microsoft started putting MVC into the .net framework.
I ask because I don't know how to design things very well and thought I was doing well to emulate what's on the asp.net site with Scott Mitchell's tutorial. I thought that creating abstract layers in a BLL was the way to go until I found out about MVC and now asp.net's MVC.
I honestly don't know what the "right" way is to do things. I just create what I need, but I can't help feel like I am missing something.
Is MVC the correct way to start doing things in large projects, specifically I mean MVC and ASP.NET, but could just as well mean PHP and one of their MVC frameworks.
I'd like to settle on a standard way of doing things...for now anyway.
And, out of curiosity, why did Microsoft only now start doing MVC?
UPDATE: Is MVC better than the current tutorial set on asp.net?
I'm referring to the Scott Mitchell tutorials where he creates the BLL for abstraction. Or is that a linq question as well. I should have said that I understand the need for keeping logic and presentation separate but unsure the best way to do it. I was using the asp.net tutorials. It worked fine. Then I found out the rest of the world, as I saw it anyway, was using MVC. Then Microsoft started developing MVC, so to me the other method seems obsolete and the wrong way to do things.
No, it's not the only best way to do things.
MVC is just a design pattern. The goal of all design patterns is simplicity. So as long as it makes your design simpler, go with it. If it makes things more complex for your specific application, try a different approach.
Unfortunately, some people think if they see a pattern, they should use it. It's just not true. Design patterns don't inherently make your application better. They are not an end. They are a means to an end (which is simplicity). So you should use them only if they are worth it.
In my opinion, over-architecting things without a good reason is worse than writing code without any specific design.
EDIT: Regarding ASP.NET MVC: I have a negative personal bias toward ASP.NET Web forms. Before MVC, I did most of the dynamic aspects of advanced projects by writing custom handlers to have fine grained control over the HTML. Web Forms make Web development very easy but they have particularly a couple things that are good but sometimes are problematic. The first of which is ViewState and the second is complex WebControl architecture. Don't get me wrong. Those are signs of brilliance of ASP.NET. I haven't seen a single platform for Web development as easy as ASP.NET Web Forms and this is only because of great WebControl support which requires ViewState. However, in some projects, you want to have precise control on rendered HTML (specially when you have some client-side logic). You also want to make server side code maintainable in large projects. In those areas, ASP.NET MVC really shines. But I think ASP.NET Web Forms will remain a great technology where it's more applicable. After all, as I said regarding design patterns in general, you should carefully evaluate your design to see which one better fits your needs.
Specifically, about data access, MVC usually requires more code than Web Forms counterparts. For presenting tabular data (i.e where GridView is applicable), I think ASP.NET Web Forms is the easier way to accomplish things. However, most data driven Web apps are not just manipulating a table directly in a database. They have complex layout. StackOverflow is a great example of this. It is certainly data driven, but ASP.NET MVC better suits it.
There is no "right" way to do things without knowing what "things" are. MVC is a design pattern that solves a specific common problem - separation of presentational and domain logic. Every design pattern is a commonly accepted "good" solution to a specific problem.
Those solutions, combined with knowledge and experience are building blocks for a good design. The "right" way to do things is to study your problem domain, research on possible solutions and apply the set of solutions that work best to solve it. Making mistakes is a part of the process as well, so don't be afraid to experiment and then refactor with rigor until you reach the solution that serves you best.
MVC is the worst way to develop applications, except for all other ways that have been tried. :-)
Joking aside, MVC is one application design that encourages us not to write spaghetti code. It's a guideline that reminds us to keep business code separate from presentation code. This is very helpful as the application gets more complex.
There are other variations that achieve that same benefit, but are not strictly the same as MVC. Presentation-abstraction-control (PAC) is one example.
As for why Microsoft is so late in adopting MVC, I'm not surprised that they are. They are pretty well-known (at least in recent years) for being conservative instead of innovative. They prefer to let other smaller companies take the risks in an unproven market, then they learn from the mistakes, churn out an overengineered competitor solution, and dominate through marketing.
Example: Microsoft Internet Explorer was considered to be a latecomer to the browser market. Netscape had become very popular, leading the way in providing a platform for people to view HTML. Once the amount of HTML content on the Internet was at a useful level, Microsoft belched up their onomatopoeic "IE" product and quickly captured an overwhelming market share.
MVC is just one way of doing things. I like it because it helps to promote extensibility and is structured to allow testing and code reuse. There is no silver bullet, one true way to do everything but I use it quite often.
In regard to Microsoft, I would say that they adopted the pattern as an alternative to WebForms development for the reasons I mentioned above. I would recommend looking at Rob Conery's MVC Storefront and kind of play around with the examples to see how it works for you.
There is no "best" way to code things. It depends on the application in question; sometimes MVC is the right choice, and sometimes it's not. A good developer is able to weigh his/her options and choose the one that's best suited for a task at hand, instead of just going with the method du jour
If MVC solves the Primary Technical Imperative of managing complexity in your application then it may be a good solution, but it is by no means the only solution.
MVC is one of any number of design patterns. Whether it's the best technologically, or the simplest, or for what types of projects it's appropriate, are are all arguable (see other SO threads). In any case, few would argue against the prevailing consensus that for most cases, it's "Good Enough".
But it has the undeniable benefit that a lot of people use it, on a lot of different platforms.
So if you want to use a methodology that is likely to be around a while; or you don't want to depend on one vendor for support and extension and refinement; or you work in a group that would like to grow by hiring people from various backgrounds who will grok a shared methodology quickly; or you would like to maximize your opportunities to move on if you need to, then MVC is one of the very best ways to support those goals.
MVC being "Better" or "Worse" pattern is relative to the project.
I'd like to build a CMS site based on Asp.Net Mvc and I want to choose my starting point.
I have seen that there is a lot of interest in the new Microsoft Oxite project also if it seems to be pretty early to adopt it in a production project.
I've also looked at S#arp Architecture but it does not properly compare to Oxite as is just a starting point for general Asp.Net Mvc sites.
For me S#arp Architecture has some advantages over Oxite as is far less complex and it uses Nhibernate for the data access layer.
Oxite code uses Linq2Sql for it's DAL and has already a project in the solution that requires the DB version for VS2008.
Oxite seems to me more blog oriented than CMS oriented but I haven’t looked the code deeply.
Here are some of the choices that would point me to S#arp Ar. for starting.
Simple clean architecture
Nhibernate Dal
Community supported
Oxite:
Microsoft project
Potential huge community
Early stages but very good code quality
Provider model that permits to easily switch the DAL
If anyone has looked at the code of these two projects please advice on your opinions.
Thanks
Oxite might be feature rich, but the code quality is very low.
I was very surprised when I checkout the code and found controller actions with 100+ lines of very unclean code, tagsoup views, no unit tests, etc.
The criticism has been well summed up in these blog posts:
http://blog.wekeroad.com/blog/some-thoughts-on-oxite/
http://codebetter.com/blogs/karlseguin/archive/2008/12/15/oxite-oh-dear-lord-why.aspx
As always, it depends on your needs. It sounds like you need something more CMS based. Oxite happens to have some CMS-like features, but it's not really a CMS. It might be in the future as it's a community project, but right now it isn't (all you can do is add content pages).
We're glad everyone seems to like Oxite overall, but it is pretty early. Not to deter anyone from using it in production, because we do. We run MIX Online on it, but totally understand if you're not comfortable with it. We need a stabilization period. At the same time we also need people running it so we can make it stable. Chicken and Egg I'd say. :)
I didn't get much of a response at my question about Oxite here at SO (found at Oxite: What are you going to do with it?), but it is really new so it'll take some time for people to warm up to it and fully check it out. The architecture of Oxite is really easy to get started with; that's its strongest suit.
I'd never heard of S#arp before I read your question so I'll definitely check it out.
Oxite is well detailed already, entirely negatively.
I'll just add that I've been using S#arp architecture for several months and found it very maintainable and flexible. There's also a very solid, growing and active community of users around it.
It is very clean, and quite easily upgraded to Fluent NHibernate RC 1.0
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. :)