I am considering rebuilding my ASP.NET portal using ASP.NET MVC. I use the same portal solution at two different web sites, and I would like to have a single place og editing and writing articles for my sites - a management site. I have considered making an "Article Web Service" that would provide me with the functionality of creating and listing articles - but how about performance?
On my portal i need to fetch all my articles to make a list of articles (full list - ~100 articles) then show a single article with comments. The same applies to forums, blogs, media gallery, and so on.
I think im blinded of the opportunity of providing me - the administrator - with an easy to use interface in one place where i control all the portals.
Would the extensive use of webservices slow my portals down so much that they become useless? Is there an alternative solution to doing this single point of administration, an alternative to WebServices?
cheers,
Sounds like a good idea for your architecture.
If you expose your database via a service, it creates a really great separation between your UI and back-end, so you can write WPF, Silverlight, ASP.NET, WinForms UI that all consume the same service(s) if you so desire.
You might want to look into WCF which gives you great flexibility as to where the services live and who consumes them and how.
Also, with a reasonable amount of effort you can implement things like caching and compression, which will alleviate any performance penalties you incur by the additional layer you'd be introducing.
For a straight MVC-based portal, you shouldn't need web services, unless you're making heavy use of Ajax or Silverlight -- but in those cases, the web services are called by the client, not from the server-side. Server-side WS are generally reasonably expensive from a performance perspective, and make sense only in certain limited high-scale, multi-server applications.
For your admin tasks, just build a set of protected pages with a UI that controls the admin functions you need. If you're feeling adventurous, Silverlight can be good, too.
If you're looking for some ASP.NET perf tips (though not wrt MVC), you might enjoy my new book: Ultra-Fast ASP.NET.
Related
At the moment I am starting to learn Silverlight. I have expriences in ASP.NET and like the concepts of "Masterpages. Does Silverlight provides a similar concept ? I have read a little bit about the Silverlight Navigation Framework. Is this a good replacement for "Masterpages" ?
Makes it sense to combine ASP.NET and HTML (with Javascript) with Silverlight or is it more recommandable to design and write pure Silverlight applications ? Mybe in the ner future I will start to develop an intranet (business) application which will have many and complex user interaction (it should behave like a windows client applicion). I think Silverlight is the better choice than ASP.NET !? Makes it sense also to start to use/learn the WCF RIA Services immediatly ?
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ? Unfortunately I am missing "Starter kits" on http://www.silverlight.net like the starter kits on www.asp.net !
Thanks in advance for your hints.
Silverlight and ASP.Net are light years apart technology wise, Silverlight is closer to Winforms programming than it is to ASP.net, event though it can be hosted inside an ASP.Net page.
To achieve "masterpage" type functionality, you can have a base control or page that you can inherit everything else from. Or you can have a page which acts as a shell and you can swap views in and out depending on the user's actions.
If you are writing an app from scratch, you can do the whole thing in silverlight. You can navigate from one silverlight control (hosted in an aspx page) to another aspx page (with silverlight controls in it), but there is a performance overhead when transitioning between aspx pages (they are web pages and need to be served). You should look to eliminate separate aspx pages if possible, and create it as one big silverlight application - if your application's functionality is all rolled into one application (not spread amongst aspx pages) then you can make the most of Silverlight's Out Of Browser feature.
However you should only consider silverlight if you are build web apps or interactive/streaming stuff. If your pages are going to be largely static (i.e. presenting product catalogs, or a site where the user just drills through from one page to another) then using silverlight would be overkill, you would be better off sticking with ASP.Net or ASP.Net MVC.
Masterpages does Silverlight provide a similar concept ?
Not directly but it does provide a variety of ways to acheive the goals of Masterpages. The navigation framework is mostly the sort of thing you would need to achieve the typical reason to use Masterpages.
However its also possible to achieve "masterpage" functionality more generally by creating a UserControl that has ContentControl instances at points where in ASP.NET masterpages you would have used a asp:contentplaceholder. These content controls would be bound to custom properties added to the UserControl. This completed UserControl can then be used as the "LayoutRoot" of another UserControl or Page. Note this does not require inheritence from the "master".
Does a combined ASP.NET and Silverlight app make sense?
Well thats a tricky one the answer really is, "It depends". There are way to many factors to give this a true answer. Factors:-
Is this a public app or an internal app?
How important are including rich UI features?
First time Silverlight dev will cost you, is your project able to absorbe that?
What client platforms do you need to support?
How might ASP.NET-MVC + appropriate use of JQuery size up against your requirements?
Probably others I haven't thought of yet
Is Silverlight is the better choice than ASP.NET when there are many and complex user interactions?
The phrase "complex user interactions" could mean a couple of things? Do mean complex to deliver with HTML and Javascript but simple for the user? Or is this a sophisticated app aimed at an expert user?
In either case its likely that Silverlight will start to come into its own here.
Does make it sense also to start to use/learn the WCF RIA Services immediately?
Yet again the answer depends of the type of application you have in mind. If its line of business app where data is searched, edited and reported on then (assuming you have decided to develop in Silverlight at all) definitely you should be looking at WCF RIA Services as well as the parts of PRISM that think are appropriate.
Other types of apps may not benefit from WCF RIA Services.
Are there good (VS) templates to start with Silverlight or which are a good basis / starting point for a new Silverlight application ?
There are no start kits at present. However I think you will find what you need amoung the various demos and tutorials on the silverlight learning site.
I've particular found the videos useful. If you decide to go Silverlight its well worth clearing a day or two to got through the relevent ones.
These are a lot of questions at once.
Yes, the Navigation Framework functionality is pretty much equivalent to the Master Pages concept. Even to the point that it is tracked in the URL when users navigate, so they can use the back and forward button of their browsers.
If you want to do a stand-alone Silverlight application or a hybrid pretty much depends on your requirements and on the type of application you want to develop. If it's a Line of Business application, you might be doing fine with Silverlight alone.
For a public, content/text-intensive website probably HTML with some silverlight gadgetry here and there might still be preferable.
I watched a little introduction into ASP.NET Dynamic Data, and I noticed this option to create a data driven website for the first time. I have a database with a few tables, just created a Dynamic Data application out of my database and well... my application with a lot of nicely looking web pages, navigation between them and all kinds of CRUD operations was finished after 3 minutes.
OK, seriously, it isn't finished of course. There is a lot of custom logic to introduce, design to change, and also pages or relationships to remove I don't want actually to see in the web application.
But now I am wondering if ASP.NET Dynamic Data is at least a viable starting point or do I better start from scratch and create page by page? I could imagine that it might be useful to create a quick database maintenance web interface but is it good for a very customized web application? Is it in the end more complicated to modify the scaffold than building up everything from the ground?
I'm very interested in your experiences or recommendations regarding Dynamic Data! Thanks in advance!
I could never wrap my ahead around it enough to get any use out of it. At first, I thought this was Microsoft's answer to Ruby on Rails, and I was looking for the same benefit. I don't it comes close to having the same benefits. When I then compare it to a CMS (DotNetNuke, Sharepoint, Drupal, etc) it then looks really underpowered. Compared to ASP.NET MVC, it seems like going the wrong way from basic ASP.NET (MVC is removing bad abstractions from ASP.NET, while DD is adding even more abstractions).
Personally I'd rather build something from scratch in ASP.NET MVC, though my day job is regular ASP.NET. I'm also learning Drupal as I haven't found the sweet spot with ASP.NET based CMSes. One thing at at a jobsite you're going to want to use technologies everyone else knows. So I think that limits where knowing Dynamic Data is generally useful, as basically any legacy application won't be using it and you're unlikely to find a team with existing ASP.NET Dynamic Data experience.
The quick scaffolding is spiffy but at the end of the day I don't think it will make web development easier.
I very like ASP.NET Dynamic Data as it is a fast way for creating data driven applications. Customization is not a complicated task.
I wrote a corporate website with this technology from the scratch - it takes appr. 2 months for all. So my point of view that this is a good starting point for web applications development.
if your archetecture resembles ASP.NET Dynamic Data or DotNetNuke or some other starter kit, go for it, if
application is small to medium sized
you do not have strict deadlines
you are learning the technology.
otherwise or when you will be skilled in particular technology, you will prefer yourself working from scratch as it gives you more freedom and space for the implementation of ideas.
For e.g, one reason for the breakthrough for Asp.Net MVC had was many .Net developers wanted freedom over the development / architecture / flow and rendering (HTML) of the product they were building. Asp.Net WebForms does provide solid and vast grounds for swift development and templates but developers had to go according to the architecture. This freedom is available under MVC and developers can make use of nearly all Libraries and skill set available and go their own way.
one successful sample is Stackoverflow.com itself
hope this helps
One of the common questions asked regarding ASP.NET MVC is why should you use it over ASP.NET Web Forms? The answer generally includes ViewState and clean URLs, amongst others. Towards the end you'll find a blurb about using the right tool for the job and that they serve different purposes. However, I don't believe I've ever seen what those purposes are. So, when would you actually choose ASP.NET MVC over ASP.NET Web Forms, or ASP.NET Web Forms over ASP.NET MVC?
You don't choose ASP.Net MVC over ASP.Net, because ASP.Net MVC still is ASP.Net. You do choose ASP.Net MVC or ASP.Net Web Forms, and there are lots of good reasons to do that:
Easier to get control over your HTML
Easier to do unit testing
Few "Gotchas"
On the other hand, Web Forms do have a few points in their favor:
Easy to put simple CRUD/business apps together extremely fast
Hard to beat ViewState performance in local LAN environment
Easy to learn forms paradigm
The result is that if you're building business apps in a corporate LAN environment (which honestly is still most web developers), Web Forms is really great. In that sense Microsoft really knows their market. But if you're building an app for the public internet, you might want MVC so you can test thoroughly and be sure your pages aren't bloated with unnecessary ViewState or JavaScript data.
Additionally, something that has changed over the last several years is that even many corporate intranet applications now need to support home/remote use, making MVC more attractive to that crowd than it had been.
Use MVC if all your team members are skilled enough to manage "control over HTML", otherwise your code will turn into a tag soup.
In other words
bool useMvc = true;
foreach (TeamMember member in team.Members)
{
useMvc = useMvc && member.IsSkilled;
}
http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx
check that blog !
Bottom line "separation of concerns"
I'll give you a couple purposes, with clear advantages.
If your purpose is a public facing website that will be banking on traffic, use MVC. It is optimal for search engine optimization.
If your purpose is an enterprise web-application that acts like a desktop app, I would lean towards web forms, since state management and compartmentalization of your resources into underlying server controls offers huge advantages if used correctly.
The biggest problems facing developers is managing complexity and keeping code "clean". MVC gives the developer the reins to leverage OOP to tuck away complexity and make code easy on the eyes.
Webforms will be faster to develop in the short term, but it doesn't lend itself to long term sustainability in terms of maintenance and growth.
I've worked with Web forms for 13 years and MVC for 2 years now and when I started with MVC, I had similar questions. Here are my takeaways.
Most importantly: ASP.NET's latest release is 4.6 and they were moving to ASP.NET 5.0, but MS abandoned that for ASP.NET Core, which no longer supports Web Forms (or even VB.NET). So, that alone might give you your answer when deciding what rabbit hole to go down.
That being said:
MVC I'm finding, once you get the hang of it, is WAY easier for dealing with basic forms and any sort of simple "Model", aka tables with a very simple, straight-forward set of relationships such as orders that have tables that link to users, products, etc. Once you start getting into some more complicated relationships and need to return lots of conditional sets of results, rely on parameters, have complicated stored procedures... then Web Forms is much better for dealing with this. If you don't have to deal with this level of complication, MVC makes development SO MUCH faster, especially with dealing with an approach where you already have the DB because it creates so much of the code and validation for you already
If you're not very experienced with database design, MVC does the work for you. It can literally build the database for you.
MVC doesn't have a lot of the built in controls that Web Forms does (Gridviews, FormViews, Sitemaps, Paged lists). Everything has to be written from scratch, but luckily a lot of people have already invented that stuff for you in NuGet which you can just download into your project
MVC relies heavily on the structure of your URL. The path, the querystring, etc. If you find your application needing to do a lot of form POSTing instead of GET-ting, you're going to have to do a lot of tweaking or AJAX posting. If you have a set URL that can't change, it can be a pain. It's doable, but just a little tricker (or you can just use Angular instead).
MVC has no Viewstate. If you need to hide variables from post to post and persist them, it's a little difficult. MVC Does have things like ViewBag which lets you pass data from your controller to your page, but it clears after the page is rendered. There is also something called "Tempdata" which acts like Session state, but more temporary. However, it relies on Session State which is not an ideal way of persisting data. Session variables and tempdata variables are fine for user-level data (profile information for the person logged in), but having two different tabs open by the same user can cause these session/tempdata variables to overwrite each other when you're dealing with the actual model data.
If you're at a crossroads, I'd go with MVC. MS is pushing it and support for Web Forms will likely start going away
Last week at Mix '09, the final version of ASP.NET MVC 1.0 was released.
Some of the stated benefits of this framework are:
Clear separation of concerns
Testability - support for Test-Driven Development
Fine-grained control over HTML and JavaScript
Intuitive URLs
Now, Microsoft are being careful to tout this as being "an alternative, not a replacement, for ASP.NET Web Forms", but given the advantages mentioned above, I'm wondering:
How long will it be until "classic" ASP.NET Web Forms is considered to be a "legacy" framework?
If you were kicking off the development of a new .NET web project today, why would you choose to use Web Forms instead of the ASP.NET MVC offering?
Good questions. I think ultimately, the answer is going to be the development team's expertise and the project needs that will decide that. ASP.NET web forms is so heavily used that it likely isn't going away anytime soon. Plus, there are so many custom controls and third-party support such as components and books. The main benefit of web forms is how easy it is to get a dynamic website up and going. It really is a RAD way of developing websites.
However, once that team has more experience with creating larger websites with much higher demands in terms of scalability, reliability, and test-ability, then they will look towards other solutions for that. In this case, they will realize that web forms are harder for unit-testing. They may also see that viewstates reduce performance and look for possible solutions.
Although MVC has the stated benefits, it is unlikely that anyone will convert their sites to use this new framework right away or ever. Plus, it requires the team to learn the new technology, and work out the new bugs. The team will have to learn new ways to do the exact same thing. For example, how easy is it to support uploading a file using MVC?
As I saw recently, there isn't a reason you can't create a site using MVC and web forms together. So you may see more hybrids in the near future. But I doubt that web forms will ever go away.
I kind of think about web forms like the way VB1 changed the way Windows applications are created on the desktop. To this day, the RAD way of creating application still exists and will never go away.
Keep in mind that MVC STILL uses WebForms for it's default View Engine. Sure, you can replace it with another one, but WebForms is still a core part of it.
Also, not everyone prefers to tightly control the HTML or the Routing. That's not my attitude, but some people just want their job done with the smallest effort.
And aren't .asmx Files technically part of the "old" Model as well? I can say for sure that a lot of people would not like to see them go away.
Still, I personally see ASP.net MVC becoming the main Web Engine for ASP.net in the future, although not in .net 4.0 yet.
You're asking when a newly-released web platform, ASP.NET MVC, will replace Web Forms, which has been around for seven years.
If we'd been crying out for ASP.NET MVC for the past seven years, then it wouldn't have taken seven years before ASP.NET MVC was released. The fact is, not everyone sees a need for this. Many of us have been creating complex, highly-scalable web applications for most of those seven years.
We even knew how to make them testable, and to separate presentation from business logic and data access. ASP.NET MVC may enforce this separation, but I've done it by using coding standards and code reviews, and by saying, "there's no unit test for that", and "get that business logic out of the UI".
Also, if I really needed more control of the HTML, I would write my own control to generate the HTML.
I do not believe WebForms will ever retire.
I've been using WebForms at work in business applications and MVC at home for some private things. Though I really like MVC I do not see how this could be possible to implement really complex UI logic with HTML/CSS/JavaScript. It will quickly become unmanageable and will be quite unsecure since JavaScript can be switched off to prevent disabling some controls or hiding some information. On the contrary, turning off JavaScript with WebForms will virtually turn the page dead for any action, either authorized or not.
Both platforms will continue to evolve. For general web sites and HTML/CSS lovers MVC is a way to go, with complex applications you would want object-oriented architecture and artificial event handling even though it abstracts you from the stateless nature of HTTP.
So, pick up what is best for you.
P.S. Dropping WebForms altogether will jeopardize the future of numerous projects and companies throughout the world. Microsoft folks would not want to become an object of hatred and the trigger that started the third world war.
WebForms will still have a place for those that want a pseudo-stateless web application that they can easily put together by dragging and dropping. For those that don't have to or want to understand how HTTP works. It's the ultimate in RAD for web applications.
ASP.NET MVC on the other hands allows much more finer control at the cost of more responsibility. You get complete control over your HTML however that means you have to sanitize/encode your output yourself. Your application for the most part has to be completely stateless and for some ASP.NET WebForms/Windows WinForms developers that it's a bit hard to wrap their mind around.
I don't think either will ever dominate the other though one may be favored.
We need to build an administration portal website to support our client/server application. Since we're a .Net shop the obvious traditional way would be to do that in ASP.Net. But Silverlight 2 will be coming out of beta a good while before our release date. Should we consider building the whole website in silverlight instead, with a supporting WCF backend?
The main function of the portal will be: users, groups and permissions configuration; user profile settings configuration; file upload and download for files needed to support the application.
I think the main reason for taking this approach would be that we have good experience with WPF and WCF, but little experience in ASP.Net. Either way we would have to learn ASP.Net or Silverlight, and learning Silverlight seems a more natural extension of our current skills.
Are there any big no-nos from the experience of StackOverflowers? What are the big positives?
I would recommend against building a pure Silverlight site.
Silverlight suffers from the same issues as Flash does: Unintuitive Bookmarking, issues with printing, accessibility issues, not working back buttons and so on.
Also, you would require your users to have Silverlight installed or at least to have the ability to install it.
In controlled environements (eg. in large companies or health care) or on mobile devices, this might not be the case.
I would definitely go for a full Silverlight application, specially if you have good experience from WPF. You will be able to reuse your knowledge from WPF, and should be able to pick up Silverlight fairly quickly. I've been working with Silverlight since Beta 1, and the current Beta 2 is of solid quality. I guess it's safe to assume that a RTW version is just around the corner.
Pilf has some valid point, specially around printing. For that I would probably use SQL Reporting Services, or some other reporting framework, on the server side, and then pop up a new window with printable reports. For linking and bookmarking the issues are no different than any other AJAX application. I did a blog post today about how to provide deep linking and back-forward navigation in Silverlight.
Silverlight also has all the hooks needed for great accessibility support, as the UI Automation API from WPF is brought into Silverlight. I don't know if the screen reader vendors have caught up yet. The styling/template support in Silverlight makes it easy to provide high-contrast skins for visual impaired users if that is a concern.
Depends on your goals. If administration portal is part of application and will only be used from computers where your application is installed, there are plenty of advantages of going fully Silverlight - or even WPF.
But if you can see a scenario where it will be used either from random PC or by random person, fully functional HTML/Javascript version is absolutely necessary.
Some reasons are:
Most people don't have silverlight and you'll earn a good load of swearing if they have to download and install it. Some people who have it installed keep it disabled (together with flash and sometimes even images) to avoid distractions and speed up browsing.
When HTML site fails, user gets error page and reloads. When silverlight fails, it can hang or crash.
HTML is what is expected - both by users and web browsers: back and refresh buttons work as they should, hyperlinks and forms work as expected.
Slow internet is still very common, both in remote areas and mobile devices.
I agree with what everyone had said so far and I think this Flow Chart, which is aimed at Flash, also applies to Silverlight.
Source of Image
It sounds like your problem is that you need a rich-client admin application. Why not use click-once?
On the topic of remote andministrators, another poster stated that was an argument in favor of HTML if the admins were on a slow connection. I would argue that depending on the type of information, it may be more efficient to use Silverlight. If you have an ASP.NET datagrid populated with server side data binding, you can be downloading a ton of markup and viewstate data. Even if you're using an alrternative to DataGrid that's lighter on the ViewState, you will still have a lot of HTML to download.
In Silverlight, once you get the XAP down, which is probably going to be smaller than the corresponding HTML, the XAP is cached and so you shouldn't have that cost every time, and you'll just be retrieving the data itself.
For another example, let's say you have a bunch of dropdown lists on one of your forms which all have the same values in the list. In Silverlight, you can get these values once and bind them to all of the dorpdowns, in HTML you will have to repeat them each time.
This will get better with client side data binding in ASP.NET, which follows a very similar model to Silverlight and WPF for data binding.
Overall, I would also think that you would need to write less code for the Silverlight implementation which can increase productivity and reduce maintenace costs.
ASP all the way. You should only use silverlight/flash etc when text can't do what you want it to do - e.g. display video.
Using a plugin for your website makes it slow, and requires the user to have the plugin installed. Silverlight for instance rules out all Linux user. Also, since Silverlight is pretty new, there is no telling how committed Microsoft will be to keep the platform alive if it doesn't pick up soon.
I'd stick to plain old HTML with server side scripting.
Also, for public websites: Flash and Silverlight can't be indexed by any search engine, so good luck with writing tons of metadata if you want any visitors at all.
Silverlight is a good choice for an internal-facing portal, just as it would be for a public-facing portal if you've already evaluated your project and have decided to go forward with a web portal. You are free to integrate Silverlight components within an existing ASP.NET application (i.e. the "islands of richness") approach, but if you have the ability to build a new project from scratch, don't discount a completely Silverlight solution as a valid choice where you would have went with a traditional ASP.NET portal. Silverlight is RTW now, so if this decision is still on the table, you know you won't have to deal with breaking changes going forward.
There are some downsides with developing a site completely in Flash / Silverlight, but if those downsides won't matter to you or won't have an impact then there is nothing stopping you. Choose whatever tool you think meets your needs more fully. I wouldn't be put off creating a site purely in Silverlight based on the downsides, because it brings a lot more positives to the user experience.
The previous comments have dealt with most of the downsides of using Silverlight for a site like this and I agree. If you're determined to have rich-client style development and your audience is small (for admins only) then I'd probably recommend WPF over Silverlight as it currently provides a richer set of tools and controls.
If you stick with ASP.NET have you looked at Dynamic Data - it's ideal for building backend management sites with little effort.
I've seen "Silverlight only" websites at Microsoft and they are pretty impressive. But again, the demos were there to exploit the full potential of what Silverlight can do. The moment you need something different you may be out of luck. I don't see Silverlight like Flash except in the way they are installed/seen. But the Flash/ActionScript backend is really bad compared to what Visual Studio can offer with .NET
Ask yourself why would you like to use Silverlight? Fancy effects or programming model?