I know there's tons of questions about .NET based CMS out there, but I have some specifics things I'm looking for.
1) Be able to leverage our application's existing authentication (We have our own implementation of of System.Web.Security.MembershipProvider as well as MembershipUser)
2) Be able to restrict who can view certain pages/segments based on our custom roles, in addition to restrictions on who can edit them.
Maybe most of them support this, but I haven't had much luck finding which ones specifically satisfy these requirements.
(Being lightweight is also a plus, I've read about Orchard and N2)
I don't know how much this will help you but here goes. We did a search last year for .NET content management systems and I wasn't super thrilled. There are a ton of commercial systems that are really expensive and appear to be crap.
I checked out N2 first. It seemed really clean, but it was way too barebones for our purposes. We would have had to do a ton of custom development to meet our needs. It's really a CMS framework instead of a CMS product.
Umbraco was the other system we took a serious look at. It has a lot more features built in and it's a fairly nice system as long as you don't mind a little XSLT. It does use the standard membership provider framework, so that's in your favor. I don't really know whether the roles will do what you want though. But since it's free you can play with it to see if it meets your needs.
As for Orchard, I don't know much about it. It wasn't around when we were looking, but it seems interesting. I couldn't tell in a reasonable amount of time how it handles membership and roles on the back end. It does seem like it's geared towards smaller sites, so it might be a little limiting in that respect.
We've been using Telerik's Sitefinity product with custom forms authentication. You can use forms authentication out of the box or you can customise it. It does make use of the provider model too.
More information on custom authentication can be found here.
I would suggest looking into AxCMS (at AxCMS.net). It is complete, pluggable and has extensive documentation. Specific documentation about their implementation of Membership and Security is available at : http://help.axcms.net/en_help_concepts_security.AxCMS
Microsoft's Scott Gu recommends it here at http://weblogs.asp.net/scottgu/archive/2006/02/02/437220.aspx
EPiServer is a commercial ASP.NET based CMS. It is essentially a set of .NET assemblies that you reference and build into your ASP.NET application to turn it into a first class CMS.
It makes use of standard ASP.NET features like the provider model so you can swap bits out.
Related
I've started to wondering whether ASP.NET Webforms/MVC even have a place in the web developers toolbox anymore... It seems that CMS systems like Umbraco have replaced the web developers job. Yes I know that those CMS systems are built with ASP.NET Webforms/MVC - however is there even any reason for learning those things if all you gonna do is to use a CMS system anyway? - Also I cant find any situation where a CMS system can be replaced by your own web application.
My question is therefore: Is there any reason for learning Webforms/MVC when using a CMS?
EDIT:
My question might be more like: When should I use a CMS, and when should I go and build my own web app?
The problem with CMS solutions, and I mean all CMS solutions (not just Umbraco, or other .NET solutions, but in any language) is that you will always pay a price for using them. You may gain more from the time-savings afforded by using the CMS, but there are trade-offs to consider:
You will sacrifice a great deal of flexibility
You could pay a significant performance penalty. Many CMSs load a large amount of modules and code to service every request, and much of this is not relevant to a particular page function. (though some CMSs are more monstrously heavy than others!)
The future of your project is tied to yet another vendor, and their own choices
Very often, you rule out the possibility of using other databases that might have better fit your customer's needs (Umbraco doesn't support PostgreSQL, Kentico only supports SQL Server)
Once you start using a CMS you will be tied into satisfying the architectural decisions and API of the CMS framework, and you could eventually be backed into a corner.
This can be particularly problematic if your 'site' is more of a web application than a pure content delivery site. In such cases it can make more sense to choose to build using the full flexibility of the web application framework, rather than risk getting backed into an architectural corner.
On the other hand, if you are building a web site that has potentially hundreds of pages, with a lot of user-contributed content and is much less of a web application, then often a CMS is the way to go, and makes a lot of sense. But remember, you now have two frameworks and two APIs to learn and manage (your platform's framework and the CMS framework).
Writing a CMS is like invading Afghanistan.
Everybody gets a turn but nobody wins.
I don't think that Stack Overflow could have been built with a CMS. Does that answer your question? =)
Update
To answer your updated question.
If you want a regular corporation web containing news, articles, forum etc: Go ahead and use a CMS.
If you need to build a more custom web site like stackoverflow, a web interface for a system or anything like that: Built it using MVC etc.
I personally use a CMS for our corparate website and a MVC framework to build user and administration interfaces for our products.
Not every problem needs a CMS. In the same way not every problem needs a bespoke MVC/webforms website. It depends on what your requirements are. You pick the technology to solve the problem.
Build vs buy is the hardest decision to make. As a developer build always looks best. You can do better than that pile of carp they want to buy. Nevermind that you're reinventing the wheel, axel, cart, etc. To users/management buy always looks best. They don't have to think to hard about what they want and can have it now, not 3 months later after you write it. They forget it'll cost the same again to customise & make it impossible to upgrade.
I'll stop ranting now.
Umbraco is a pretty bare minimum CMS. To customize it (e.g. Version 7+) you'll need to know Heavy MVC, JSON, XML, Sql, etc.
In fact a Site built on Umbraco 7+ is entirely based on MVC views you set yourself and assign to SurfaceControllers (which are MVC controllers) and all you are really getting is the ability for users to edit things about your pages and have Umbraco manage it for you in a DB.
In short you still need experienced web developers to build a site on Umbraco, they just save a lot of time by not having to build the entire backend from scratch.
You use Umbraco to organize Document Types that define what Templates (MVC Views) are used for rendering different types of documetns (e.g. Web Pages) and then you built the template from the ground up with 100% control over the HTML, Css, and Javascript that get's output.
Imo Umbraco is more of a Framework like Django than a complete CMS.
Sure you can build a site in Umbraco and not customize anything, but it would be a pretty cheesey site.
The whole point to Umbraco is to give skilled .Net Developers a good platform for building a site on top of it, but they still have to build it.
Now sharepoint would be more of a complete CMS out of the box that you can do a lot with, but let's see a few problems with SharePoint...
Resource Heavy, eats 50+ Gig's to install
Eats 16 GB of ram just to boot it up (Sharepoint 2013)
Requires Sql Server 2008 R2 or equivalent (enterprise license, $$ chaching)
Requires Windows Server ($$chaching)
It's a monster basically, if all you need is a user editable blod platform... man what a waste of money. Foundation is free, but doesn't include things like the Blog Site Template, so you buy a server enterprise license ($$ big cachinge, 40,000$+ in some scenarios...)
Agreed. A CMS like Umbraco provides a (very) good out-of-the-box solution for the most basic applications. Any sort of specialized purpose is going to require additional programming knowledge. Anymore, though, and your major, if not primary need is going to be a good understanding of the business need. I think we're getting away from building the Legos themselves and on to building the neat toys with the Legos. Cheers!
A CMS (or similar application framework) will provide you with a lot of functionality out of the box, and many of them also have a good library of plug-ins. But you'll still need to write WebForms/MVC code if you want to add any custom features.
Through a lot of sticking my head in the sand, reinventing the wheel and general stubbornness, I've managed to go all this time (years) avoiding learning the built-in ASP.Net support for web application authentication, users and roles. Part of the reason is that rolling my own originally seemed like less work than getting my head around all the different layers of optional abstraction provided by the ASP.Net security framework and as such I came up with a nice library that worked fine for me.
I'm now trying to go back to using as much of the built in functionality of ASP.Net (MVC2/3, not WebForms) as possible, as I've found that the more non-standard functionality you build into an application, the harder it is for other developers to pick up your code and work with it.
The web is thick with half-tutorials, badly explained articles and information that excludes important beneath-the-hood information about the ASP.Net security framework.
Are there any good tutorials that rip the lid off ASP.Net security and show you how to use it and how it all works without trying to push you through wizards and specific provider models without understanding all of the options and their pros and cons?
This is a 18 part series articles from Scott Mitchell.
It's a very deep explanation of all the features that regards Authentication, Authorization and Membership providers in asp.net. I did never found a better source on this from the same author.
MSDN is the best for ripping the lid off: http://msdn.microsoft.com/en-us/library/ff647070.aspx
There is the requirement, to write a portal like ASP.NET based web application.
There should be a lightweigted central application, which implements the primary navigation and the authentication. The design is achieved by masterpages.
Then there are several more or less independent applications(old and new ones!!), which should easily and independent be integrated into this central application (which should be the entry point of these applications).
Which ways, architectures, patterns, techniques and possibilities can help and support to achieve these aims? For example makes it sense to run the (sub)applications in an iframe?
Are there (lightweighted and easy to learn) portal frameworks, which can be used (not big things like "DOTNETNUKE")?
Many thanks in advance for you hints, tips and help!
DON'T REINVENT THE WHEEL! The thing about DotNetNuke is that it can be as big or as small as you make it. If you use it properly, you will find that you can limit it to what you need. Don't put yourself through the same pain that others have already put themselves through. Unless of course you are only interested in learning from your pain.
I'm not saying that DNN is the right one for you. It may not be, but do spend the time to investigate a number of open source portals before you decide to write your own one. The features that you describe will take 1000s of hours to develop and test if you write them all from scratch.
#Michael Shimmins makes some good suggests about what to use to implement a portal app with some of the newer technology and best practice patterns. I would say, yes these are very good recommendations, but I would encourage you to either find someone who has already done it this way or start a new open source project on codeplex and get other to help you.
Daniel Dyson makes a fine point, but if you really want to implement it your self (there may be a reason), I would consider the following components:
MVC 2.0
Inversion of Control/Dependency Injection (StructureMap for instance)
Managed Extensibility Framework
NHibernate (either directly or through a library such as Sh#rp or Spring.NET
A service bus (NServiceBus for instance).
This combination gives you flexible user interface through MVC, which can be easily be added to via plugins (exposed and consumed via MEF), a standard data access library (NHibernate) which can be easily configured by the individual plugins to connect to specific databases, an ability to publish events and 'pick them up' by components composed at runtime (NServiceBus).
Using IoC and DI you can pass around interfaces which are resolved at runtime based on your required configuration. MEF gives you the flexibility of defining 'what' each plugin can do, and then leave it up to the plugins to do so, whilst your central application controls cross cutting concerns such as authentication, logging etc.
What do large websites built in .NET use for their login components?
I will be implementing the login and membership features of a large .NET web application. As I see it, there are 4 options:
Leverage the default Microsoft Membership Provider
Build a custom Membership Provider
Use a different 3rd Party Component
Build an entirely custom login/authentication framework
I am trying to optimize for reliability, so I would like to know if sites like MySpace or PlentyOfFish have already established a best practice in this area. The real motivation for this question is I want to validate that the MS Membership Provider strategy will scale well.
I know StackOverflow uses OpenID, but I don't think that would be a good solution for what I am working on as a lot of my prospective users will be non-technical. Feel free to pitch why OpenID should be considered if you believe strongly in it.
Always rely as much as possible on platform-provided tools for security tasks such as authentication.
In this case, that likely means inheriting from one of the stock MembershipProviders. That will let you re-use all the existing code for the provider, plus any tweaks you need to make it work with your existing system. It's possible you can find a 3rd party component that works well for you that already does this.
I've got an upcoming project that is going to be dealing with 70,000+ users (education). I was wondering if the ASP.NET SqlMembership Provider has been used at such large capacities? Assuming the hardware is there, is there anything special that needs to be done to make it work smoothly? We're doing all the obvious things like separating boxes for databases and applications, but is there anything code wise that I need to watch out for?
I know one site that, owner of this site wrote a brilliant article about asp.net performance(http://www.codeproject.com/KB/aspnet/10ASPNetPerformance.aspx)
On this article there is one subject that author describes a patch about profile provider for higher performance. Please read that section.
Inbuilt SqlMembershipProvider is very reliable and workable. They tightly integrate with FormsAuthentication and Login Controls. So authentication is reliable and it is also quick to implement.
Only problem I see is the complexity of the Database table structure, they are quite tidy and not so straight at first. So you can basically write your own MembershipProvider that will talk to your own users table with more simplistic design and implementation. Also Managing Members on admin is also painful due to table design but in a way it is fairly possible to do so. For these reasons we wrote our own MembershipProvider based on Sql. It's working amazingly and we've had good experience of the same.
If you have a small website or project
you can straight go on with inbuilt
SqlMembershipProvider but for a large
project like yours I'd recommend
writing your own MembershipProvider.