we've got an existing webapplication written in magic. But now we eventually want to exchange the existing web-presentation layer (maybe also rich client) to a server side presentation layer. What do you think I should look first (ASP.Net MVC, Silverlight, something in PHP).
With which technology is the effort relativly small to exchange the presentation layer if you only have a model.
And is it maybe possible to use a generic presentation layer so that we could create the new pages with small effort.
PHP vs ASP (or anything other such as Ruby on Rails, etc) is all about preference and what you know or think you want to ramp up on. Let me talk about this from a Microsoft web developer perspective, assuming you choose to go down that path.
If you have a pretty simple data in / data out app, and don't need a lot of dynamic screen interaction and want to develop features quickly, then ASP.Net is the way to go. You can do a lot of dynamic stuff with Javascript and web services, but ASP.Net is not as flexible as something like ASP.Net MVC. However, its much easier to develop an entire screen quickly in ASP.Net using server side controls.
If you want greater control over your HTML output, you want a more dynamic display with Javascript, and want to be able to more easily leverage unit testing, ASP.Net MVC is the way to go. Developing simple screens will take longer than a traditional ASP.Net app, but developing interactive content where server generated DOM needs to mesh well with client-side manipulation will go faster with MVC. Unit testing is also a snap with ASP.Net MVC, and there are plenty of example out there to show how to build a well-tested MVC site. I would argue that ASP.Net MVC might also scale better since you have more control over the output.
If you need a really pretty UI with rich graphics and animation, and want to be able to unit test your application logic, then Silverlight using the MVVM pattern is the way to go. I am writing just such an app right now. Its pretty easy to unit test (as easy as any unit testing ever is), easy to mock out data to test the UI with large datasets, and Silverlight provides a level of graphics you cannot get in HTML. Having said that, you will be dealing with a smaller audience using Silverlight as the plugin is required to view Silverlight just like Flash. Silverlight isn't available on the iPhone as well. Silverlight also incurs a downloading time penalty, so you have to do some thinking about how big your app is which isn't so much the case with a "pure" web app.
A mixture of ASP.Net and Silverlight or ASP.Net MVC and Silverlight is your fourth choice. You might do this where only parts of your application require the rich UI that Silverlight provides. Silverlight and ASP.Net projects can share files, so you can use classes you develop for business logic in both places (with a few caveats).
I hope this helps, and good luck with your project.
Related
Ive been doing a bit of research / reading into mvc recently and was just wondering what the main purpose is.
is it as some people say to seperate the logic from the html
or to create clean url's
i could be missing the point completely, but asp.net forms really seperates the logic from the html and if you just want clean url's why not use a mod_rewrite rule?
MVC is a software engineering concept which is used more widely than just in ASP.net.
In a nutshell it encourages strong separation of:
business logic (the Model) the code which does all the brute force work behind the scenes; dealing with the database, performing large calculations; and
user interface logic (the View) the code which presents information to your users in a pretty way.
The C is for Controller - the ligaments that bind the bones of the model and the muscles of the views and allow them to communicate with each other cleanly.
You are correct that 'normal' ASP.net uses code-behind files so that page markup is kept separate from the code that generates that markup (in contrast to languages like PHP where code is embedded directly amongst HTML), but MVC ASP.net encourages even more separation in the ways I described above.
Take a look at this tutorial for a more detailed discussion of the pattern. Also take a look at this SO question
The MVC pattern has nothing to do with rewriting URLs. ASP.net MVC might make this easier but that is not by any means it's main purpose.
Testability is a big benefit of using ASP.NET MVC. It is non-trivial to write unit tests for ASP.NET winforms. It is much easier to unit tests for Controllers.
If you are doing MVC correctly, your views should be very light, and a lot of your logic is implemented in the Controllers.
Let me compare the two for you:
Asp.net web forms
They matured the old ASP technology that was much more like PHP. Code and presentation were piled up in the same file. Asp.net web forms upgraded this model by providing a mechanism of separating the two. But they built on top of the good things that windows application developers had. The drag drop interface creation with control events just like they exist in a windows application. Event thought code was separate from HTML, they were not separated. You still reference a lot of view controls in your codebehind, hence they're still very much bound to eachother.
Therefore it was rather easy to start developing on Asp.net web forms. But non savvy developers soon got to a bottleneck they didn't know existed (like slow postbacks due to huge view state etc.). Technology used some tricks to make this work. But on a serious large scale application this became quite a problem. Developers had to mingle their code to make it work with Asp.net web forms framework. Their complex forms had complex codebehinds with hard maintainable code with complex state.
The good (as well the bad) thing were at that time rich server controls. Nowadays with web 2.0 they don't seem rich anymore since they don't actually support client side functionality as much as they should. So Microsoft decided to also cram in something else. Update panels. That made partial rendering (and Ajax) possible with almost a flick of a finger. But it came with a cost. Everyone that used (uses) it soon realised it's not a viable solution that a professional application could implement.
Asp.net MVC
Now we have a new technology that doesn't have much in common with Asp.net web forms except for its first part of the name. MVC framework actually does separate code from user interface (view). Controller actions (code that executes on any HTTP request) is kept small and doesn't do anything with visualisation (it doesn't bind data to certain controls etc.). Controller action barely prepares data for the view to either consume or not. It's up to the view. Controller code doesn't in any way shape or form reference any view controls or anything. They're actually separate in MVC.
Views on the other hand just display and provide data. They can be partially or fully rendered. They support Ajax functionality to the point that everyone would like to use. Actually everything is separated into basic little things. Divide et impera (divide and conquer) seems to be the save-line here.
There's not hidden functionality. No flirting with windows development. It pure request response framework. Developer has the ability to 100% control the visual aspect of their app. But for the cost of not having rich controls out of the box. Those may be provided by the community or some developers prefer to create per purpose controls that serve the process much better.
Which one is better then?
Both have their pros and cons. But if you decide to build a semi complex, modern and maintainable application I'd suggest you give MVC a go.
But if all you need to do is a 15 screens application (without any particular interface requirements) it would be much faster to create it using Asp.net web forms.
MVC is a design pattern. Its purpose is to separate business logic and presentation details.
ASP.Net MVC is a mechanism to create web applications using ASP.Net and the MVC pattern.
One of the features of ASP.NET MVC is the ability to use SEO friendly URLs to provide commands to the controller part.
You can do as you have stated but ASP.Net have provided you a mechanism to do this easier.
The way ASP.Net Webforms was designed is that it made it easy for you drag controls on to the web form and code the logic underneath. ASP.Net MVC is designed so you separate your concerns easier.
The URL part of the ASP.NET MVC framework is just a modern phenomena to produce search engine friendly urls. They've infact been around long before the Microsoft team decided to add them to the framework (which required IIS7 before it could be done with no IIS extension).
The greatest pros in my view come from being able to test more easily, and separating off the parts of your application more cleanly. The whole ActionResult architecture of the ASP.NET MVC framework makes it very easy to switch from AJAX to plain out POSTs.
Delphi 5 use to employ the MVC model for its ISAPI extensions, 10 years ago.
MVC is not just an ASP.net thing, it is a design pattern that was widely accepted before it was created within the .NET framework, the thing about MVC is the separation of data from presentation(user interaction) from the business layer. It was just a way for Microsoft to offer that type of design pattern under the .NET framework
Although guys before me already give enough answers to the queston of purpose of ASP.NET MVC there is one thing I would like to add.
The ASP.NET Web Forms tried to abstract html and web from web development. That approach lead to the lacks in performances and usage of rich javascript frameworks.It was possible to create web application without actual knowledge of the web.
And to answer to you initial question, the purpose of ASP.NET MVC, I'll quote Dino Esposito:
With ASP.NET MVC, you rediscover the good old taste of the Web—stateless behavior, full control over every single bit of HTML, total script and CSS freedom.
MVC existed long before people tried to use it in HTML pages. The main reason for MVC is to get a grip on the logic to drive your application. MVC allows you to clearly separate things that should be separate: The model, code which converts the model value for the display and the code which controls the model.
So this is not related to HTML or URLs in any way. It's just that MVC makes it really simple to have clean HTML and simple URLs.
I'm frustrated recently by all of the choices that Microsoft offers to develop a web form. There is Sharepoint, Infopath without Sharepoint, ASP.NET Web Forms (with different controls for each runtime), ASP.NET without Web Forms, ASP.NET MVC framework, Silverlight, and WCF. Rendering and databinding technologies aside, there are a handful of different ways to pass data to and from the database (DataSets, LINQ, SqlDataControls, and many more) And those are only the ones that I can name in a minute or so - I'm sure I'm missing some very old technologies (did FoxPro ever get a web front end) or very new things in the process of rolling out of Microsoft Labs.
If I want to move away from using ASP.NET Web Forms and DataSets, what's the best way to move right now for data driven forms? What have you worked with that delivered good value for your programming time? I'm tempted to try working with LINQ to Entities and the new MVC framework, but I don't know enough about all these new technologies to choose where the value lies.
It's been said many times before - there is no "what's best". If any of these tools were best, than the rest wouldn't exist. "Data driven forms" is a pretty broad requirements statement.
They all have advantages and disadvantages in other areas, but all of them are capable of "data driven forms". MVC is lower-level forms - you will have to put in all the HTML and form processing yourself, however, it is much closer to dealing directly with HTTP, so lots of people find it much lighter-weight and easier to work with.
Silverlight has drawbacks in that it uses a diminished set of the .Net libraries, and requires the users to install browser plugins.
WCF would provide the data behind your forms, and would be very suitable if you're planning on opening up a public API or consuming the data in other ways.
You may find it beneficial to research each technology for even an hour each, and you would have a better understanding of which might fit your needs.
If you're using ASP.NET (which, when trying to code a regular website, feels a little "shoehorned"), then I thoroughly recommend trying Microsoft's MVC framework. It's a real breath of fresh air!
From a value per working-hour POV, it really depends on what you're doing. I can't say I've tried many web-frameworks, so I may not be the best metric, but using MVC everything fell into place naturally and I'm happy to stick with it for now.
I don't think ASP.Net Forms is something you need to "get away from".
MVC certainly has it's usefulness and when appropriate certainly makes a lot of stuff simpler.
But a well designed ASP.Net Forms app can be just as or even more useful in certain situations.
Myself I use MVC for public facing sites and Forms for internal/administrative stuff.
For a data-heavy page, I think web forms is a perfectly adequate solution. MVC introduces separation of layers which may make it harder for you to develop, since it forces you to separate the gathering of the data and routing it.
I'd say MVC is nice for having an interactive web page (Web 2.0-ish) but if you are simply showing a bunch of reports, or making users fill out forms - there's not much for you to take advantage of, IMHO.
As an alternative, try writing less code with built-in controls like Repeaters or DataGrids or even DataSets. Getting down to the core of your data flow allows you to be more productive by writing smarter code - not necessarily by writing less code.
In the end, I've found that I put together my own "framework" that does exactly what I need. I get HTML directly from a custom control. These controls simply format the data being fed by procedure calls to my custom Database access class. And yes, these are all served up with web forms or http handlers (ASHX) and a little bit of jQuery.
So while it's not glamourous, it gets the job done faster and better - by developing code that is fine-tuned to my business, not to some abstract software design pattern.
It seems to me that, for structured development with both depth and breadth of capability, ASP.NET MVC and Silverlight have the potential to make a nice powerful framework with superior UI granularity and reduced AJAX exposure. Have any of you tried building such a stack with future durability in mind?
ASP.NET MVC and silverlight?
In some ways, it is an either-or choice - your data is displayed either in html/css/js generated by ASP.NET, or in Silverlight. Why mix them? I'm sure that ASP.NET MVC is a good way to deliver Silverlight, but that doesn't necessarily make it part of the same UI.
It's generally about reach vs. richness. A web UI with no Silverlight or Flash can reach more users, but one with Silverlight can have a richer UI. Silverlight is good fun to code in, and I have seen some wonderful apps using Silverlight's streaming video features, but if e.g. you are doing data entry and display, and you don't need the richness of Silverlight, then why not keep the reach and stay in Asp.Net?
If you are going to do the UI in silverlight it makes sense to do all of it in Silverlight. I have had good experiences with all the ViewModel-view-controller page flow happening inside the Silverlight app, rather than transitioning to another html page and loading a different silverlight app. It's faster and you can do fancy transition or fade-in effects in Silverlight's XAML markup.
Why is "reduced AJAX exposure" a desirable goal? Sites like e.g. Stackoverflow here use AJAX techniques to very good effect.
Stephen Walther's talk at MIX09 shows four pillars of ASP.Net as it currently stands - Forms, MVC, AJAX and Dynamic data. A lot of people are Seeing it as "moving from forms to MVC" but there are other approaches also being developed in the mix.
I've built a little test app with SL and MVC. It didn't work that well but I don't think I was doing right. I've tried using SL in views but its slow to switch pages since its loading new SL instances all the time. I've tried a single SL app which meant it contained all the control code as well but that relegates the server to data access which only needs some WCF/Web service code no need for MVC there.
It may work better if we dispense with the idea of there being many view pages. In my next iteration I shall be using controllers to respond with XML or JSON directly to requests from a Silverlight app which contains the views. However this approach would still leave some questions unanswered, for example, how does the controller get to have a say in what view is actually displayed?
To be honest, I'm getting the feeling that SL to ASP.NET-MVC are yet shaping up as a good match. Some web apps may benefit from some SL elements (charting for example) yet the app remain firmly in HTML. On the other hand, an app whose UI is purely in SL (whilst internally using some similar View/Controller concept) doesn't really need MVC on the server-side.
Its early days, it will take while for us early adopters to see what really works and what doesn't. There being a beta for version 3 with more coming from MS in the way SL can access serverside data may change things further.
I asked a similar question here: Does Silverlight 3 Change the MVC vs. Silverlight question. This was in response to SL2 vs. MVC where folks all agreed that they were complimentary technologies. I'm still not convinced. My experience has been similar to AnthonyWJones. Per the previous posts, I tried to mingle them without a lot of success. Could be my own ignorance, though. Right now I'm building a Silverlight only application using SL3 beta. I seem to be a lot closer to my intended effect. That being, an application with a few database features. So it didn't make sense to build a completely stand alone app (since the data is central), but I really wanted some Silverlight goodness to render the end result and allow the user to interact.
So where in the hell am I going with all of this? Based on my experience, this still seems like a YMMV type question. It really depends on what you're trying to build. Since I'm light on database, heavy on interaction, I'm biting the bullet with Silverlight 3 and .NET RIA Services for the little database stuff. If I were writing Stackoverflow, I'd probably do ASP.NET MVC and AJAX.
We are currently using ASP.NET MVC as an alternative to WCF to expose data to Silverlight where our Silverlight app makes RESTFUL calls to urls in our Mvc application and the controller returns a JsonResult which works well for us. It's by no means necessarily the text book way but we found this way the two technologies compliment each other. Now if we ever need an HTML implementation we've already done the Model-Controller work which can be re-used.
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'm starting a new project soon and investigating whether or not to use MVC, Silverlight or both. This question Silverlight vs. ASP.NET MVC was a good starting point. But looking over the SL3 beta, it looks like there are two things that change the landscape just a bit. First, the navigation feature which is a direct feature of Silverlight and now there is the .NET RIA Services. While not actually part of Silverlight, it's fairly integrated and seems to bridge the gap between client and server operations. An area, in my opinion where MVC is strong and Silverlight (being a client side technology) was not. I understand that you can still use both, but should you and why?
Simply put, no.
Silverlight and silverlight on the desktop are more like winforms/wpf applications that just happen to run on the web. They're stateful and act very differently from a web site. Silverlight apps can only be run on machines that allow silverlight to run. In a business network setup they may have group policies setup so that silverlight cannot be installed. Then you've got a problem.
ASP.NET MVC however is a stateless type of design where pretty much anyone with a web browser can get to regardless of platform. You have much more freedom with your site using ASP.NET MVC because you don't have a dependency on the end-user having any sort of runtime installed.
I think each has their place and it's pretty much obvious. Silverlight is great for creating a rich experience where applicable. I doubt you'll see too much silverlight popping up replacing web sites.
When we built .NET RIA services we looked to enable developers to basically build out rapid RIA's 100% and as a result we targeted the approach in terms of taken over the burden of ASP.NET WebForms etc. To use the two in a hybrid fashion is possible, but it's a question of which piece do you want to take over the heavy lifting.
If you're Silverlight solution is basic in terms of implementation - ie datagrid of data only - then ASP.NET MVC is a better fit as this way you're not having to worry about deep linking etc (as that comes free inside a native HTML based approach).
If however you're building out a larger RIA solution within Silverlight and are using ASP.NET in ways that are specific, then ok thats fine, but you're going to have to remember that with every page refresh comes a penalty that is of course a page refresh and secondly you need to ensure the said Silverlight instance can find its way back to where it was before you hit the refresh (that or loads in a place that enables the user to find its way forward).
It can be somewhat very tricky despite the goodness we baked into RIA Services.
Scott Barnes / Rich Platforms Product Manager / Microsoft.
I think that both technologies have their places - I think Silverlight will be used mainly for special purpose applications and asp.net MVC will be mainly for public and general purpose style webpages and web applications.
As to which one you want to use, well that depends entirely on your needs and your audience.
Silverlight is coming along nicely even for business applications (Navigation, RIA Services, Data Form etc...) But ya the big problem is the plugin.
Personally, I'm sick and tired of HTML so i'm focusing efforts on Silverlight.
It also depends if you're working on a site for fun or not.
A lot of websites built for businesses and organizations have a "read only" public facing front end. That is, information (inventory, catalogs, corporate news) are presented from a rich database, but the average end user has no ability to edit them.
The natural pattern I have been seeing is to use ASP.NET MVC for the "front end" presentation but to use the Silverlight / RIA functionality to avoid having to write all the CRUD stuff int he administration back end. It is a great fit. The administration userbase is usually much smaller than the total audience and issues of download time, Silverlight penetration and so on are not nearly as problematic.
However the Silverlight RIA / ASP.NET MVC story is a very fuzzy one right now. There isn't much information discussing how to use RIA Services to provide access to a shared repository project of the style you build for MVC projects. link text This makes integrating them difficult right now. You could build both your MVC and RIA layers on top of a common EF or Linq2Sql base but it makes sense to share the intelligence of the Repository classed you build for MVC.
Ideally, we will get good documentation of connecting RIA Services to a Repository style class layer, independent of what the Repository uses to talk to the database underneath and then the rapid development story will be complete.
I dont think silverlight changes the asp.net MVC story.
MVC lets asp.net be more web standard friendly, and forces projects into a more testable, decoupled structure. The later was the sole responsbility of the architect/developer in webforms.
"Personally, I'm sick and tired of HTML so i'm focusing efforts on Silverlight."
Amen to that. javascript too.
I've been developing web apps for over a decade (Classic asp then jumped to .Net as soon as it was in beta). MCTS x2 and MCPD x2 in asp.net.
While i think ASP.Net MVC is great additon for web site developers, i do think web forms with a strict MVP pattern in UI layer is often still better for enterprise / B2b web applications. (dashboard, administration, reporting etc.)
That all said as i move into more into the integration space, SOA, biztalk, wcf etc.
I really am over the giving a sh1t weather this css property is applied validly in "IE version what ever". or "firefox version whats next" and over dealing with the sometimes great sometime want to shoot myself control hierachy in web forms.
Silverlight 3 is really starting to become relevant for LOB applications, i see it as the major compeditor to webforms, not MVC.