I aim to try use DevExpress web server controls (which are awesome) in an ASP.NET MVC project (some articles I read on 'net seems to indicate the two can work well together).
I'm eager to start a new project using ASP.NET MVC, and I have been reading up a lot on ASP.NET MVC lately, but I'm not sure if I should invest a project in it. My concern is that it may turn out to be like LINQ to SQL, which is essentially been killed off since MS will not be providing updates.
Is ASP.NET MVC a viable solution to invest in my case?
Yes definitely ASP.NET MVC or any other MVC framework is worth learning. MVC pattern is all about seperation of concerns and helps you to keep your code clean.
If you like Devexpress control too much you could be disappointed because there is no server side control in ASP.NET MVC. But if you want to learn Web's underlying mechanism,HTML, Javascript , clean code, TDD ASP.NET MVC is a good way to go.
Learn first, experiment later
Asp.net MVC is a great development platform for building web applications, so it's definitely worth your time to learn it through and through.
But I suggest you first learn MVC framework and build at least one semi complex app with it and then start experimenting with mixing MVC with web forms controls. It is possible but as much you think you will gain you'll probably loose more. So I would be a bit reluctant and advise you not to match these. At least not on a Greenfield project.
In other words: presumably knowing Asp.net web forms would you suggest someone to heavy use dynamicly created user controls in their web pages if they're just about to learn the technology of Asp.net web forms? Probably not. Or mixing web forms with ASP pages on a greenfield project...
Instead try finding great either MVC-friendly server extensions or client-side libraries that will help you create rich web apps like ExtJS (I don't work for ExtJS llc, but I used the lib on a project in the past and liked it a lot). Using something like this you won't loose stuff from MVC and gain great user experience and rich functionality.
Seeing how you're asking the question on this site, I'd say YES!
DevExpress has a bunch of MVC specialized controls, that use Ajax to get data from the server via callbacks. You can see demos of the controls here:
http://mvc.devexpress.com.
I am not sure if you can use the web forms controls, my understanding is that you can't.
Also, regarding LinqToSql, you don't have to use that. I am using NHibernate for the data layer and it works very nice with MVC.
I worked with asp.net and web forms for more than 5 years and at least 1 year with the DevExpress controls for asp.net, but now I love MVC so much that I think I don't want to go back to the web forms anytime soon.
Hope this helped.
Related
I am going to start work on a SaaS based application. I need to decide whether to go with ASP.Net MVC or web forms application. Through various posts I came to know that both are good, they are not replacement of each other and so on.
Also, I know traditional web forms method, I am not aware of MVC, I need to learn it first.
Please guide me which approach is better.
Thanks,
Vijay
i can just share some of my experience as i have worked on both
i preffer asp.net MVC over Asp.net because of the futile layer of abstraction that Asp.Net has over basic HTTP architecture
the user controls in asp.Net induce unnecessary markup
ease of using ajax in asp.net mvc compared to updatepanel(in advanced senarious)
support of razor type syntax increases productivity
no overloading by things like viewstate
because everything is managed by the programmer soem of the typical issues that arise in asp.net like the problems in dynamic controls are no longer present
so if you ask me go for asp.net MVC
There is no right answer here. I prefer MVC but if you already know ASP.Net WebForms it probably is easier to stick with that.
I'm a big fan of what ASP.NET MVC is doing, on many levels.
I'm about to take part in re-build of a very highly trafficked website, and I'm not which framework would be best (if any).
The site will need the following:
To support Javascript-heavy, highly interactive pages
But at the same time, provide underlying semantic HTML for search engines
Support multiple languages
Be skinnable
Expose a RESTful web-service API for partners
As far as I can tell, there's no reason not to use ASP.NET MVC for this.
I can present semantic HTML and layer Javascript on top using jQuery.
Multiple languages can be catered for using Resource files (same as at present).
Skinning can be done with CSS (it won't involve changes to the markup).
I can centralize business logic so that the Controllers and the WCF web-service use the same code.
But are there potential drawbacks to using MVC that I haven't considered?
I don't want to be the guy who picks a technology because it's cool but finds later down the track that it isn't very suitable for the job.
ASP.NET MVC is not good when all your doing is making a website that needs server-side code (but that's also true about ASP.NET also).
In your case I think MVC would be a great way to go. MVC has proven itself on high traffic websites (e.g. this one). However you must remember that MVC is new and changing. A library may not exists to do a specific task which means you'll have to write that code yourself.
Good luck on your rebuild!
You're good to go with MVC given what you've said about your project.
As far as I'm concerned, ASP.NET MVC is really only NOT good for situations where you have a large codebase in WebForms (meaning you have a lot of ASP.NET user controls, custom controls, etc). It's also not good if you are going to have people working on it who don't know what it's all about. Other than that, it's a pretty nice technology.
My two cents:
ASP.NET MVC is a great option but there is a little learning curve involved, so make sure your project plan/timeline has this handled. There might be developers on your team who might not be comfortable working with ASP.NET MVC, and this can cause possible delays (a lot of developers are still working in ASP.NET 1.1!).
#Alex: Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
IMO the idea of using controls in ASP.NET MVC doesnt make much sense. You can create a treeview control using jQuery easily. Classic ASP.NET server controls carried a lot of baggage (viewstate etc) and hence ASP.NET MVC did not use any of those controls (though you can use helpers).
Finally, ASP.NET MVC is an alternative, not a replacement to Web Forms. I would not use ASP.NET MVC as it is still evolving, and my team is not very comfortable with it, but I guess slowly more and more programmers would shift to this (better) option.
I do not like ASP.NET MVC because of following reasons:
1.
Ugly routing API, there http://ayende.com/Blog/archive/2008/11/05/a-case-study-of-bad-api-design-asp.net-mvc-routing.aspx
is description of what is wrong.
By the way, friendly urls can be easily implemented without mvc
http://demo.liveui.net/bugtracker/Tasks/7
2.
Poor object model. It is proved that good software should consist of reusable components. There is nothing that can be reused in ASP.NET MVC based web site. For example, if you implemented smart drop down list once it will be difficult to use it again (even on the same web site).
3.
Lack of controls. Some features (like TreeView or Menu) are already implemented as Controls and it would be waste of time to reimplement them using mvc.
If I were you I would try to find some CMS and customize it for WebSite needs.
To responses:
YES. I know about ASP.NET controls disadvantages, but the question is about ASP.NET MVC. One can write a book about what is good and what is bad in ASP.NET but I do not think it is appropriate to discuss it here.
There are better ways of implementing MVC without using asp.net MVC. I have done it in the past, even before asp.net MVC came live. MVC is a pattern, not a technology, I do not understand why some people call it a Technology. You can separate all concerns by removing the code-behind from webforms and create your own controllers and routers and you will still have the advantage of the webform controls, etc to which most asp.net developers are used to use. asp.net mvc is nice for people whom do not really have the time to properly create an MVC app in a webforms environment and also to those whom do not have the time to architect a better solution. in conlcusion, asp.net mvc is good but there is a much better way of doing it and finally, MVC is NOT a technology.
This is a difficult question to ask because it's so wide ranging.
Does anybody know of a scoring system of questions that would aid in choosing between a WebForms and MVC application at the start of a project?
e.g. Is TDD an important part of this project? (If yes score 1 for MVC and 0 for WebForms)
I would consider the following:
Current Skill Set of the team. If you have a large team that aren't going to pick up MVC quickly but are comfortable with Web Forms I'd stick with Web Forms
What level of control do you need? MVC gives you more control but that also means you'll be doing a lot of extra things your self. WebForms gives you a lot less control but there are a lot more things in the box. If being able to control the HTML output is important to you than maybe MVC is a better fit.
Will you need third party integration? There isn't a whole lot of 3rd party control support for MVC however there is a ton of support for webforms. Getting a nice grid in webforms is simple, however you'll be writing a lot of your own code in MVC to solve that problem
As you mentioned, is TDD desirable?
State management is a lot easier in web forms
I have a single question test (disclaimer: it's far from perfect, but does the job a lot of time in making you lean toward each of the technologies):
Is your application more form oriented (e.g. intranet stuff or something) or you are building an Internet-facing Web site (e.g. StackOverflow). In the first case, I'd probably go with Web forms. The latter case is probably better satisfied by ASP.NET MVC.
Another thing: these two are not the only paradigms out there. Before MVC days, I've done several projects by building HTTP Handlers that do the routing and other stuff that MVC does. You could also strip the Web form part of ASP.NET and just use non-server-form Web controls (while you'd do it in a standard Web forms project, I can hardly call this style ASP.NET Web forms).
Unless you are working on a very data centric app and need server controls with databinding and viewstate, I would go with MVC.
I haven't made anything serious in web form since MVC preview 2. MVC is much better with regard to design patterns and best practices.
And yes IMO TDD is very important and gives more than 1 point to MVC.
Usually, the decision to use WebForms or MVC boils down to controls. If you are going to be using a lot of server-side controls, then WebForms is for you. If you don't have that burden then MVC, at least in my opinion, is much cleaner, and more testable.
After using both of them the way I decide now is: Do I need to use server controls? If I don't then I default to MVC.
If you were stuck with WebForms for some reason then you could implement the MVP (Model-View-Presenter) pattern to separate the view from the logic and have some hope of unit-testing the codebehind.
I work for a small website company (couple of programmers, couple of designers). Currently we use ASP.NET website projects - this makes it easy for me to sort the programming out on my local machine, while the designers work directly on a development server and the 'on-the-fly' compilation allows them to see any changes made without having to compile and deploy the website (and all tied up with SVN).
I'd like to start using ASP.NET MVC for pretty much all the reasons that makes it different from Webforms (logical urls, no viewstate, more control over html, unit testing etc..) but don't want to make the dev process over complicated, so:
Any reasons you can't set MVC websites up as website projects instead of Apps so they don't have to be explicitly compiled throughout the dev process? (Our 'live' websites all use web compilation projects anyway).
Will this still allow unit testing?
Is there any other way of allowing the designers to develop MVC sites in the same way as they currently do? Note: They use Dreamweaver, so no Cassini development server.
Can anyone advise with any of the above (even if only to tell me my dev process makes no sense.. :)
Thanks.
ASP.NET MVC is a great platform no matter what type of project. If you already understand the basics of HTTP and how websites actually work ASP.NET MVC will be like the thing missing from your life. If you're used to the postback model of ASP.NET WebForms it may be a little harder to grasp at first but it's very easy to understate. It's basically a stateless model. Your controller is given some parameters, it writes back some HTML... end of story until the next request.
I don't think so, and I think the reason for this was to allow bin-deployable ASP.NET MVC projects. You can publish an ASP.NET MVC app straight from Visual Studio 2008 without the end server ever even having to know about ASP.NET MVC, as long as it has ASP.NET 3.5 (with SP1 I think)
ASP.NET MVC is all about unit testing, it's extremely flexible in this matter and even some of the design decisions behind ASP.NET MVC are based off allowing users to unit test their code. Scott Guthrie specifically names unit testing in the latest release of ASP.NET MVC (beta) http://weblogs.asp.net/scottgu/archive/2008/10/16/asp-net-mvc-beta-released.aspx#six
Any controls that work with ASP.NET WebForms will work with ASP.NET MVC as long as it does not rely on postback. If it does than you cannot use that control/code.
MVC is a proven design pattern for websites and even the very one you posted your question on is based on ASP.NET MVC and was built by only a few people and is now maintained by 1 (one) person (soon to be 2). I currently am using it for 3 private projects and I love it. I've seen the light and I will never go back to WebForms.
Resources:
Scott Guthrie's blog
Phil Haack's blog
Rob Conery's blog He has created an MVC Storefront demo over 25+ videos.
Scott Hanselman's blog
Stephen Walther's blog
PDC08 ASP.NET MVC Session Session was with Phil Haack and Jeff Atwood (creator of this site).
HTH!
I used to be an ASP.NET developer. Recently I started developing with Django and do so with one other developer remotely via SVN. I find that MVC frameworks make small projects even easier, and larger projects a lot less painful than oldschool ASP.NET did.
Templates are far easier to control and style than the web controls in ASP.NET. Separation of logic (beyond the code-behind methodology) makes it easier for more than one person to be working on different parts of the site at the same time. RESTful design centered around actions starts making a lot more sense after having to deal with ASP.NET page life cycle issues long enough. Also, the URL-driven routing and the ability to do reverse lookups means fewer hard coded links in your code, its easier to add new sections to your site, etc.
To answer some of your questions:
I'm not sure about live compilation, but its easy enough to write some simple deployment tools to automate this process.
Unit testing is often easier on an MVC framework thanks to actions in controllers compartmentalizing the logic much better.
ASP.NET MVC allows you to use webforms as the default template language, but I'd advise looking into cleaner templating languages such as NVelocity. Any HTML-centric templating system is going to be better than webforms because of how difficult it is to tame and style even simple aspects of web controls.
This site uses MVC. I think the team behind StackOverflow qualifies as a small shop. They have a lot of experience though. Still, considering how many people are involved (a few) and the number of servers, yeah, it's small. And it runs very well in my opinion.
As someone with some winforms and client applications experience - is it worth going back and learning the way traditional ASP .NET pages work, or is it okay with moving straight into ASP .NET MVC?
I'm kind of looking for pitfalls or traps in my knowledge of general C#, that I won't know from the screencast series and things on the ASP .NET site.
Here is the great thing about MVC. It works closer to the base of the framework than normal ASP.NET Web Forms. So by using MVC and understanding it, you will have a better understanding of how WebForms work. The problem with WebForms is there is a lot of magic and about 6 years of trying to make the Web work like Windows Forms, so you have the control tree hierarchy and everything translated to the Web. With MVC you get the core with out the WinForm influence.
So start with MVC, and you will easily be able to move in to WebForms if needed.
I agree with Nick: MVC is much closer to the real web paradigm and by using it you'll be confronted with how your website really works. WebForms astracts most of these things away from you and, coming from a PHP background, I found it really anti-intuitive.
I suggest you directly jump to MVC and skip WebForms. As said, you'll be able to get back to it if needed.
ASP.Net Webforms is a completely different abstraction over the base framework than ASP.NET MVC. With MVC you've got more control over what happens under the covers than with ASP.NET Webforms.
In my opinion learning different ways to do things will usually make you a better programmer but in this case there might be better things to learn.
ASP.NET MVC is for developers who desire to decouple the client code from the server code. I have wanted to write JavaScript, XHTML, CSS clients that can move from server to server (without regard to server technology). Clients are time-consuming to fit and finish so you would want to use them (and sub-components) for as many servers as possible. Also this decoupling allows your server to support any client technology that supports HTTP and angle-brackets (and/or JSON) like WPF/Silverlight. Without ASP.NET MVC you were forced into a hostile relationship with the entire ASP.NET team---but Scott Guthrie is a cool dude and brings MVC to the table after years of his predecessors (and perhaps Scott himself) almost totally focused on getting Windows Forms programmers to write web applications.
Before ASP.NET MVC, I built ASP.NET applications largely based on ASHX files---HTTP handlers. I can assure you that no "real" Microsoft shop would encourage this behavior. It is easier from a (wise) management perspective to dictate that all your developers use the vendor-recommended way of using the vendor's tools. So IT shops that are one or two years behind will require you to know the pre-MVC way of doing things. This also comes in handy when you have a "legacy" system to maintain.
But, for the green field, it's MVC all the way!
It depends on your motivations. If you're going to sell yourself as an ASP.NET developer, you will need both.
If this is just for your own pleasure, then go to MVC.
My personal feeling is that webforms will be around for quite a few years more. So many people have time and energy invested in them. However, I think people will slowly (or maybe not so slowly!) migrate. Webforms was always just a way to get drag-and-drop VB4 morts to think about web development. It kindof worked but it does take away alot of control.
IMO, there are more pitfalls in normal web forms scenarios than with just MVC. Viewstate and databinding can be tricky at times.
But for MVC, it's just plain simple form post/render things old-school way. Not that it is bad, it is just different, and cleaner too.
I can't really speak technically about MVC vs "traditional" as I have only used the traditional model so far. From what I have read though, I don't think one is vastly superior to the other. I think once you "get it", you can be very productive in both.
Practically though, I would take into consideration that most books, code samples and existing applications out there are written for the "traditional" way. You have more help available and your skills will be more useful for employers with existing applications written in the "traditional" way.
If you don't know how or haven't has experience with raw level web request / response and raw html/css rendering then MVC will would be good place to start.
You will then better understand the pros and cons of both webforms and mvc. They will both be around in the future as the both address different needs.
Though I will say webforms is a highly misused and abused platform.
So much of the "look no code" rubbish gives all who use it a bad name.
Put in the time to understand it and use it properly you'll find its a very extensible and robust platform.