As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
This question intends to be technology-agnostic. Which kind of web framework do you prefer, and when: Pure MVC or event-driven component-oriented?
Just to make the point in "technology-agnosticism", here I name a few MVC vs. component web frameworks, in diverse technologies / languages:
Struts vs. Java Server Faces / Tapestry
The new ASP.NET MVC vs. "classic" ASP.NET
Cake PHP vs. PRADO
I'm a php dev by day; however, I strongly prefer Wicket and/or Lift, especially the latter. The problem with Prado seems to be that the controller is tied to the page, rather than the logical controls on the page, otherwise, it still seems better than most other options in PHP land. I think all boils down to reusability, unless you have components that are backed by controllers, you can't separate the display all that well from the backing control logic.
MVC as implmented by all these 'MVC' frameworks seems to suck, you get a logical page with a tonne of controls and you have to handle all those on page controllers, wow, thanks, now I have MVC / n, where n is the number of controls. Most 'MVC' systems that I've seen so far, have been a mish-mash of brain-dead tag libraries, contorting request response into a single controller that has to be aware of everything on the page.
xhtml templates with js, and css wonderfully separated. Along with a few classes backing those components, and all of a sudden you're not busy wondering how complex pages are going to work, or if you want to take piece x, and drop it somewhere else.
Right now, the 'new hotness' trend is towards the MVC approach. I personally prefer the conventions of MVC frameworks, as a lot of the scut work that takes up valuable development time is done away with. That being said, the constraints tend to be fairly rigid, and a more traditional component-based approach might be needed in certain situations. All in all, it's a right tool for the job sort of choice.
The technology used is usually not matter of choice and especially in a big company you don't have many options.
If I were able to choose a technology, in Java I would pick Wicket. I have been using Spring MVC and it is good, but Wicket has a neat features that Spring MVC has not: server-side state management and encapsulation, rich component model, no unnecessary XML mapping files - just pure Java and HTML.
I'm primarily an ASP.Net developer, but I find MVC is a better way of creating functionally complex websites (typically Line-of-Business type sites) since it allows for better separation of business logic and rules from the markup used to display data to the end-user.
For quick and dirty sites (typically with a direct connection to the database) or richer interfaces, the "event-driven component-oriented" model is more effective.
Personally I would say MVC is the way to go for web sites. You have a lot more control over the HTML and CSS and at the same time the controller pattern works very well with HTTP. Event driven web programming is great for small sites or for people who are not that clued up with HTML and CSS and more low-level concepts.
I loosely follow these guidelines:
Web Forms/SQLDataSource- Quick and dirty app for internal use to show reporting or some other such data.
MVC- Simple to complex business logic for a core product.
MVC/REST Web Services/jQuery- HTML/Whatever type of client RIA's (when user experience reigns supreme).
Flash/Flex RIA- Useful when an extremely rich client is needed (think multimedia manipulation here).
There are a lot of gaps in this list of course but that just represents how complicated a question it is.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Im right now architecting a Web application and the customer is not sure about using ASP.NET MVC or any other MVC Framework (Rails, Djando or other apply also).
The customer doesnt see value in using these frameworks. They prefer to use traditional HTML and call Web Services via JavaScript to get all the data. For them SOA is very important and they want all the application to be SOA oriented. In the current development, we are returning some data to the views for the initial loading of the home page(using an ORM tool and doint all calculations in the controllers and returning the model to the view), and any updates to the page are executed calling Rest Services using JavaScript. The customer is complaining about returning data to the views using the controllers. They want all data to be returned via the web services, so the MVC framework for them is useless. What can i say to the customer to "sell" the use of the MVC framework?
What are the Pros and Cons of using each architecture?
Thanks
ASP.net MVC, you can make use of a service-oriented architecture and continue using MVC for the back end, the front end will meet your html, javascript to use (front-controller) and use SOA to connect to your back end for message passing (JSON) in your back end can have a MVC architecture to manage your services
It all depends....
You can, of course, use the MVC pattern from within JavaScript. You can also hook an MVC application into a service-oriented architecture.
I think the question comes down to "where do you construct the page" - front end, or server-side.
The benefits of constructing the page in the browser are obvious. You can scale more easily, because a lot of heavy lifting happens in the client. You are forced to create loosely coupled services, which you can compose in lots of interesting ways.
The drawbacks are perhaps a little subtler. Most search engines won't execute the JavaScript, so the HTML rendered by your services may well be invisible to them. As the number of browsers increases (smart phones, smart TV, etc.), testing this kind of application logic can become overwhelming. Practically, there may well be a limit to the amount of business and application logic you want to put into JavaScript - download time and execution time can become a problem, and it requires a lot of discipline from the development team. Depending on the page logic, you may not be able to cache quite as much as when constructing pages on the server.
Benefits of server-side page construction are also fairly obvious: you can take advantage of well-established libraries and frameworks. Your pages can be cached on the browser or CDN. By testing the business and/or application logic on the server, you can be confident it will work on all devices (though the user interface may well break). It's probably easier to expose server-generated pages in different formats when constructing them on the server (e.g. HTML and RSS versions).
Drawbacks of server-side page generation include not easily being able to pull apart different components and re-use them unless you design that in from the start. Where a web application depends on lots of services, the back-end code may not earn its keep.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Question 1)
I would like to know whether ruby on rails have gems with functionality similar to primefaces.
why i am asking is
if you go with primefaces ( http://www.primefaces.org/showcase-labs/ui/home.jsf ) developer no need to worry about javascript or jquery stuffs.
As far as my knowledge JSF is an spec , on based the spec various implementations available , primefaces is an ui framework for those implementations , primefaces has so many components based on jquery and javascript libs. More or less primefaces simply serves as a javascript wrapper.
I you use primefaces , you mainly concentrate on business logic no need to worry about UI.
i was heavily inspired by ruby on rails approach and there are lot of gems available.
what my question is , Is there an gem or UI framework available for ruby on rails similar to UI magic driven by primefaces
note: i am not looking for pure jquery or dojo stuffs, i am looking for UI component driven stuffs for ruby on rails. Guys who worked on projects using primefaces and projects using rails will understand my question 100 %.
Question 2)
I would like to know list of gems related to user interface. what i am asking is inorder to create very niche user interface on ruby on rails what are the stuffs(frameworks or gems) needed.
Many parts of the previous answer simply aren't true. It sounds like the answer-er hasn't used JSF2.0, which is what Primefaces is. JSF v1 was horribly complex and an awful experience for everyone. JSF2.0 is nothing like JSF v1, so be careful about the naysayers who admit not using JSF2.0.
JSF2.0 is an awesomely productive and fun web framework to use. It's not "corporate-ity" at all (but gets that reputation from JSF v1). It's lightweight and stays out of your way. Because it's Java (which is eventually compiled, not interpreted), it's also pretty quick.
At it's core is a templating framework: You're not limited to components, by default it's free form HTML. You have the option to use smart tags called components that can maintain state through the request lifecycle, which is handy for doing things like validation and ajax (both are really simple tasks in JSF2.0).
JSF2.0 also manages lifecycles of beans (small stateful objects you define) that can be bound to different scopes, like request, the view, session, or even application. Controllers are a simliar concept in Rails, but JSF2.0 doesn't have the concept of routes, instead you pass function objects using an EL, so it has the concept of actions instead. This makes it incredibly free-form; you can use whatever software pattern you like: I like MVVM over MVC, and I tend to use that pattern, whereas Rails is fairly strict MVC.
Component libraries are a bundle of java code and html fragments that can be plopped onto the page. Primefaces is a component library of commonly used UI widgets. Essentially, you write some JSF/HTML code and it drivers JQuery UI on the browser.
Could you use JSF2.0 with Ruby? I bet you could using JRuby. If it is possible to annotate Ruby objects with the JSF2.0 annotations (like #ManagedBean), I'm fairly certain you could make this work with a little experimentation.
Good luck and post back if you have any end up doing this!
I really thing you're kind of asking the "wrong" question here - due my previous experience with JSF (mostly MyFaces) and Rails.
I assume you're mostly at your beginnings with Rails - forget JSF, forget components and maybe even forget how you wrote JavaScript (on a JSF project). RoR is a different world and the more you get into it the more you neglect components, at least that was my case. I also kind of reinvented "simple" web programming with Ruby on Rails and gained some "valuable" JavaScript experience, but I had to let go some of my previous "wisdom" from Java land :)
There's no such UI "magic driven framework" for Rails as far as I know and I believe there's no demand for it either. The view layer, including the JavaScript integration, is (conceptually) different in a (component based) JSF application than it is in Ruby on Rails.
I personally only see JSF as a good choice for "corporate-form" applications that are written once, evolve minimally and require very little component customizations (or require some but than the time spent coming up with custom components should be reused on other apps).
JSF's view layer tends to limit you with the components you have - instead of thinking clearly about the layout of your "widget"'s HTML you tend to think about adapting an existing component to your needs, it's not unusual to hit the limits in a real use-case requirement and than you end up spending a lot of time examining the component for possible extensions and hacks. Not to mention it might be harder to adapt generated pieces of HTML + JavaScript that you have not wrote, even if written carefully it's still laying there and you have to learn yet another "small" API for each and every component.
If you look at Rails it's by design different - you write "plain-old" views (that initially take some time), for re-use you split them logically into partials (most likely as new requirements come in). When reused, partials can easily be adapted to new scenarios, not to mention you're in control of the JavaScript that comes with the markup.
Besides lots of new apps are written as fat JavaScript clients with a REST API, I can't imagine how JSF here would not be a burden as you most of the time need complete control over your HTML and JavaScript. You must and want to worry about the UI and certainly do not need yet another server + client JavaScript wrapper.
If you prefer thinking in components I would rather recommend you looking at client-side component libraries such as Ext-JS.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I was just wondering about the opinions out there. What do you think promotes faster development times for a web application? Silverlight or .Net MVC?
And could Silverlight be a replacement for a true http web application?
Feel free to rant or give as much details as necessary.
could Silverlight be a true replacement for a true http web application?
No. Just as Flash can't, Silverlight and any other presentation viewing plugin will never be an acceptable replacement for good HTML.
I can cite a million reasons but here are the highlights:
Plugin-availability (especially on other platforms, phones, etc)
Performance is awful compared to HTML
Maintenance is a PITA, requires complete recompilation and uploading. You just edit what you need in HTML.
Accessibility!
I can't comment on speed but I frankly think it's irrelevant. You shouldn't use Silverlight/Flash/whatever to build a full website.
What technology to use depends completely of your requirements. You should start there.
As far as Silverlight (or Flash for that matter) goes, you will be creating a web application but not a web site.
Disadvantages?
People will be reluctant to install Flash or Silverlight plugin.
Flash/Silverlight sites will not be visible to search engines.
People won't be able to bookmark them and share the links.
Back/Forward/Reload browser buttons will not work
No/partial support in Mac world
Advantages?
Rich UI
My personal opinion is that you shouldn't use Flash/Silverlight except in cases where raw HTML/CSS won't work. And HTML 5 with CSS 3 are quite powerful. Web is full of pointless Flash sites which do nothing interactive just present a few static pieces of information. It could easily be done with ordinary pages. Somebody thought a Flash site was cool, but it isn't. It's heavy, slow and inaccessible.
Silverlight and MVC/ASP.NET both have there places:
MVC/ASP.NET are great for things things like blogs informational web sites, online stores
basically when your application needs to be spidered by search engines.
For online applications like Turbo Tax or Sales Force basically applications that at one time where on your desktop but for many reasons have been moved to the web I would use Silverlight or Flex.
With the above in mind:
Having worked with MVC/ASP.NET and Silverlight extensively I find Silverlight development much faster once you get the hang of xaml.
This is repeated many times, but I never seen anyone mention such disatvantage of the "modern" technologies like Flash/Silverlight as lack of years of browser/usability support:
you generally can't copy text of arbitrary item
you don't have things like Stylish, AdBlock, or Greasemonkey at your fingertips to improve what "designers" think is good for you
browsers doesn't know about your forms and can't provide autocompletion or save values after crash/reload
accessibility solutions like zoom methods or third-party formatters do not work
And I can continue. From users prospective, Flash/Silverlight is a nightmare, stone-age, while HTML-based applications have all the modern usability stuff available for users.
Yes, there're development problems (nothing beats FireBug even in HTML area) but what matters is, please, be kind to your users. Even corporate people are people.
IMO - I look at Silverlight/Flash/HTML forming the "View" part of the website/web application.
If you can structure you site/application code properly, the View should be interchangeable and/or can support multiple formats of the view for the end user/device to choose from.
IMO - it is very hard to predict the user usage patterns of the site/application and there might be devices which need to be supported in the future. So, might as well develop applications which are structured in a way to help make that move a lot simpler in the future, in which case the rendering of the view can be anything you want to meet your current goals...
HTH.
A previous answer makes the statement "You just edit what you need in HTML". While this is true for a simple static web site. It is not true for a web 'application' as is stated in the OP. The functionality is not in the HTML. You might have some functionality in Javascript that yhou could edit this way, but doing edit-in-production of Javascript is NOT recommended.
For all but the simplest static web sites I would recommend that any change to a production web site or application should be managed in an source versioning system, tested, and reviewed before deploying to production. In such an environment adding a compile step is trivial.
I would never recommend Silverlight to replace what could be done in a static website. I cannot imagine that anyone would. HTML is designed for static content. Silverlight is not.
To address the performance issue: the statement that Silverlight performance is awful is just wrong. Certainly, it takes longer to load a Silverlight application than to load a web page, but once loaded the user interaction of a well designed Silverlight application is much faster than continually rendering complete web pages.
The lack of portability for Silverlight has been significanly overstated in some of the responses here. Silverlight has the same capability on MAC that it does on PC. Linux availability via Moonlight is not far behind. MonoTouch for the iPhone, soon to come Mono support for the Android and the Silverlight programming environment for the upcoming Windows Phone 7 also bring a lot of possibilities for mobile environments.
Having said all of that, I would not use Silverlight to develop many types of web applications. I would be reluctant to do a consumer oriented e-commerce site using Silverlight (or Flash) because of the previously mentioned reluctance by some to download the runtime. But for the SaaS application that I am currently doing that is not an issue, the vast majority of users a more than willing to do a small download to get the far richer user interface.
It is possible to achieve some of the same improved user interface 'richness' by applying Ajax/JavaScript, but I find the Silverlight development experience to be more productive. One thing to consider is generally an Ajax/Javascript application while giving a better user experience than traditional web application will still look and feel like a web application and a Silverlight application will feel more like a traditional windows application. This may or may not be a factor in your decision.
I find it a bit disappointing that a repsonse that misses the point of the OP and does not seem to understand the difference between a web application and a web site has gotten more up votes than some answers that were on point.
The response by Anthony is spot on.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
It seems to me like there's a lot of sheeping going on, with everyone jumping on the MVC bandwagon.
Almost everyone is declaring WebForms as evil and satan without much persuasion. Then they go on to say that Controls are evil and they shouldn't be in a Web app. How are you going to show anything without any controls?
I remember when WebForms first came out and everybody loved them. I guess in a few years, people will sheep on to the next thing and declare MVC evil because you had to actually create controls to use MVC and they'll say you have to develop an application and not worry about the controls.
The way I see it MVC can be achieved in WebForms by not including the RunAt in the Form tag.
Then if you want to retrieve data, just use Ajax.
Can someone persuade me on why I should use MVC and not WebForms?
You shouldn't arbitrarily decide between one or the other; don't plump for the MVC framework just because it's the new kid on the block and everyone's singing its praises, especially not if you're comfortable with doing things using Web Forms. Practically every existing system is going to be using the older, more established technology, and there's nothing wrong with that.
While it's true that the MVC framework does allow for even easier separation of concerns (after all, that's what the MVC pattern is for), it also brings with it the responsibility of writing more HTML, and I think a slightly greater understanding of how the web works; not necessarily an unreasonable requirement, but you could argue it'll slightly slow you down the first few times you set about using it.
To be honest, I agree that Web Forms takes a lot of undeserved flack. Granted, there's a lot of magic going on in the background, and you get less control over some of the HTML output, but it's not exactly impossible to style with CSS (you end up using !important a lot, perhaps), and it's also not impossible to get some separation of concerns, even if it doesn't meet the purist's view of what that might be. You can still write pretty horrible code using the MVC framework. If you're looking to throw together something quickly, and you're good with Web Forms, then you're going to be able to achieve that very quickly, and it's nothing to be ashamed of, is it?
That's not to say, of course, that you should stick to your guns and ignore MVC either; it's a good framework (in fact, it's a very good framework) and it does confer several benefits which you might want to take advantage of in the long run. You also have to remember that it doesn't automatically nullify everything you learned about ASP.NET 2.0, either; a lot of the supporting architecture is embraced in the MVC framework, including things like the membership providers.
In Webforms:
Both Viewstate and Postbacks have been made lot of problems and increased complexity of the web application development. Many web pages having hundreds of KB size of Viewstate that affected the performance of the applications sometime.
Developers do not have the control of the rendering HTML of web forms and Server controls that render html with mixed inline style and deprecated tags that does not follows standards.
The page life cycle of the Web Form is too complex and has the tightly coupling between all things in the ASP.net framework and a single class is used both to display output and handles user input.
Unit testing is almost an impossible task. Today unit testing is very important in modern software development especially when we following agile methodologies and practices. Since web is a stateless thing, Events, Postbacks and Viewstate are not a good way.
With asp.net MVC all these things are simplified
If these things don't apply to you and you enjoy using Webforms then stick with what you do best. Don't try to fix something thats not broken.
For more detail refer to : Shiju's blog of ASP.net MVC Vs ASP.net Web Form
I see the key advantages of MVC as:
Much cleaner and simpler architecture. No more guessing which event you have handle to hook up your data correctly. No more having to insert a hook to "fix" a data binding problem because the framework doesn't do exactly what you want.
The framework doesn't get your way as much.
Decoupled architecture makes much more of the code more easily tested.
More closely aligned with the architecture of the web. For people coming from a WebForms background this may not seem to be an advantage until you embrace it and design for it instead of trying to write WebForms-like applications in MVC. Fortunately, I had explored Ruby on Rails some before using ASP.NET MVC and had already started to write my WebForms apps in a more RESTful way.
History/Ubiquity -- despite the fact that Microsoft is just rolling it out, MVC is a well-known and highly respected pattern. It's widely used for lots of web applications in many frameworks. Learning MVC will give you a leg up if you need to switch to a different technology where they are also doing MVC -- say RoR or Java/Struts.
The disadvantages:
Microsoft's implementation is new and not as mature.
Few third-party "controls"/plugins for round-trip use -- generic grids and such, though there are lots of plugins on the client-side via jQuery.
Requires unlearning some paradigms from WebForms to effectively use it.
The framework doesn't do as much heavy lifting for you; you'll have to learn some Javascript and write more client-side code because the framework won't inject it for you.
WebForms is a great framework, but it does requires for you to dig in and understand it. And yes, you should still be an expert in HTML and JavaScript. Every complaint that I ever hear about WebForms comes from someone who didn't take time to understand WebForms. Here are my answers to a few of them.
ViewState is Evil and will slow down the page
This reminds me of the programmers who made everything a global variable. You can certainly do it, but you SHOULD NOT! It's the same with WebForms and ViewState. Don't use ViewState unless you need to, and then only sparingly. There is nothing wrong in adding 1000 characters of view state to the html, if it will bring better user experience and/or speed up development time. You can experience the same problem in MVC by littering the page with hundreds of hidden input controls, and yes I've seen it. And by the way, ViewState is not "magical" it simply stores some data in a single input control and also encrypts it for good measure.
WebForms generates "ugly" html and is littered with long ids
Well, first of all, nobody actually looks at generated hmtl (did you look at google.com for example, it's a mess?!). Second, if you really care about generating specific html, it takes less than an hour to create your own re-usable component or control, with html of your choosing. Or you can take existing control, override rendering and use that control instead. Once again, you have to know where to go and how to do it, but once you know, it will be a great productivity boost without any sacrifices. Long ids are automatically generated to ensure uniqueness across the page. If you ever get a chance to develop a complex MVC view, you'll notice that you will inventing your own long id pattern, so that you can parse the form fields correctly on posting.
WebForms disallows multiple forms per page
I've been developing for 10 years and only once did I need multiple forms. And then I figured out that I didn't. You do have to understand HTTP requests and responses and how to achieve them with WebForms, but if you do, you'll never need multiple forms, nor will you ever think about "forms" at all.
WebForms pages are not testable
Absolutely not true. Even if you don't like MVP (which I don't), there are other techniques to test anything you want to test. It is true that if you just use pages in WebForms as is and put all logic in code-behid, it's probably not going to be testable and it's not a good idea. However, just like in MVC or Windows Forms applications, you can and you should, at least for complex views, create intermediary layers such as views and controllers. I prefer encapsulating functionality into user controls which implement an interface or inherit a base class. Then the page on which user controls reside on acts like a "master controller". Individual views, or user controls in this case, can be tested because they all implemement an interface or base class.
JavaScript is hard to do in WebForms
JavaScript is actually easier to implement in WebForms than in MVC. You sure have more options! But once again, you have to know WebForms well in order to realise this. In WebForms you can "inject" javacript with reusable components and controls. Or you can use it just like in MVC or plain HTML after changing a setting on the page to keep ASP implementing id naming scheme.
Having said all this, what does WebForms have to offer that MVC does not? Encapsulation and reusability of presentation components is by far the biggest, in my opinion. For complex views, I develop individual components (server or user controls) and than a custom controller or presentation factory weaves all of them into place. Additionally, design-time html is far cleaner in WebForms than in MVC, making design and styling a lot easier for properly trained graphic designers. It's cleaner because there is no programming code in design-time html, only markup (I don't use data binding expressions). And of course prototyping is much much easier in WebForms. For prototypes I will normally ignore all of the best practices and resort to wizards and ugly code-behind code that hits the database directly.
I could go on, but the main point I'd like to make is that WebForms and MVC are very different patterns and require different sets of knowledge and mindset to deliver great solutions. Both require as much of Web/HTTP/CSS knowledge as you can get. If I had to make one recommendation, generally, but not always, for high-traffic public website (such as blog) I may lean towards MVC. For complex web application, either internal/Intranet or membership external/Internet application, I would lean towards WebForms.
WebForms work fine and if you like them, continue to use them.
Three of the big advantages to MVC model as I see it are:
ViewState is gone, which could create a fairly sizable amount of traffic over the wire.
URLs can be remapped to mean something as is all the rage now.
Scaffolding. I don't know, personally I think this is satan and encourages terrible programming habits, but other seem to think its a beautiful idea.
It also encourages a a proper separation between business logic and presentation by enforcing the Model-View-Controller pattern, but good WebForm code can mostly do that as well.
So, really, if you are fine with the overhead of WebForms, and ok with ugly URLs and don't want scaffolding, stick with WebForms.
EDIT: Oh, I did miss one major advantage of "clean" urls. And MVC application is much friendlier for SEO. It also gives you fine control over HTML, but frankly, I don't consider that much of a step forward.
I think part of the problem, is that many people don't realise that MVC isn't an M$ invention, nor is it a replacement for webforms. Certainly, people like "new" things, and people like to throw buzzwords around, particularly to improve their resumes...
Finally .NET developers have some choice, and with that choice, they are being thrust some degree of responsibility for the decisions they make. I'm not surprised many webforms developers are nervous about this responsibility. It's not been there before. Ultimately, it can make you a better developer, or a worse one. It's now up to you.
People loved webforms, because it was better than ASP (Classic). And yes, in 5 - 10 years, I'm sure someone/group much smarter than I, will evolve a new paradigm/pattern.
Be careful with the sheep lable, as in a way, by holding onto a vendor specific pattern (webforms) you are potentially a bigger "sheep".
MVC is now across a variety of platforms, and means your potential to develop meaningful and stable solutions to problems can be dramatically increased. Or decreased. It's ultimately up to you. If you're not ready to go, then wait for ASP.NET MVC to mature. But don't close your mind to anything, particularly a pattern that is very very well established!
I recommend reading Rob Connery's extremely inflammatory blog. He certainly strummed my pain with his fingers! Then go and read RoR stuff, Cake, and Struts. All of these will start showing you the vision that the guys who brought MVC to .NET have (~ish) and hopefully will inspire you to see problems differently!
There have been several, more detailed, answers here, so rather than repeat anything they have said I'll try to keep my answer a bit more succinct. You shouldn't, necessarily use MVC over webforms, just as you shouldn't use webforms over MVC - they are both tools and are more, or less, appropriate in different situations. I was first exposed to MVC quite a few years ago on J2EE, when .NET was first coming out (I'm not sure the ASP.NET MVC was available at that time). It gives a really nice, clean framework and gives more "web" applications (i.e. request/response), but you can also add in a lot more client-side functionality using AJAX - I have done some really funky things using AJAX on a php app I wrote a while ago and that is all usable under MVC.
There are some things that MVC does better and some things that webforms do better, but if you don't know both technologies you can't choose the best one for the current project you are doing, so please don't do yourself a disservice - go and learn MVC. Even if you never use it directly, it may still give you useful "theory" knowledge you can apply in other tools. I try to learn as many different things as I can, as the more strings to my bow I have, the less likely it is that I will not be able to solve a problem (for example, in that php app, I used php, hooked into a bit of ASP, and even had DOS and *NIX batch/script files performing certain functions - each tool had its place and was best suited to the job to which it was allocated).
Not me. MVC is pretty cool in a resume, but for our customers (those who pay for our work), it's not a show stopper.
They usually want applications that are right, fast and secure. That's all. They will not want to change the third layer of the client part in three years ! In three years, they will change every thing or nothing at all.
Layers are fun to architect and to code, but they cost a lot to create and to maintain and they are not relevant to our customers. MVC is pretty cool but really useless and expensive.
Unless, of course, you are developping applications for 4 OS and 3 plateforms... But you will then be a minority.
:o)
This is a stupid discussion - they are different, ASP.NET MVC and WebForms are different technologies! I'm using MVC for all new projects, but when I am faced with a need for RAD I use WinForms, because it is simple and there are a lot of controls already written by gurus.
Stop discussing this. Who wants to understand difference? Just try both technologies and you will understand by yourself.
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.