I need some help figuring out whether it'd be a good idea to use a CMS or portal solution for my latest project, which is (currently) an ASP.NET MVC application that must serve multiple customers (being a company or some other entity with a list of users) from a single installation (that is, a SaaS solution).
In addition to the core functionality, which includes document management/publishing, I also need to provide basic social features (such as blog, forum, gallery, polls, etc.). However, it is imperative that content is only visible for the customer to which it belongs, and my evaluation of a bunch of CMS and portal solutions has shed little light on whether they support this. They're pretty focused on single-user installations, and documentation on how to integrate with an existing MVC solution is pretty thin.
Essentially I'm looking for some guidance to help me discard dead-end options (the product does not meet requirements, imposes too many restrictions, is not mature, etc.) and find unexplored options before getting too far ahead with the project.
My requirements for the architecture include:
Multi-site support (using a single domain for hosting)
Watertight separation of content between customers
Full integration across components/features
SSO (single-sign-on)
Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
Ease of development and deployment
Custom logic will be written using C# and ASP.NET MVC and any products should support this
I want to stay in control
Solution should offer features but otherwise stay out of the way (for example, not force stupid idioms on me, like insisting on GUIDs for primary keys)
Active development community
No single-man efforts
Recent source control activity
Reasonable levels of documentation and maturity
Does not have to be open source
I have spent a fair amount of time evaluating products and components, which I'll briefly share here:
Umbraco
Does not support ASP.NET MVC (yet, as someone is bound to otherwise comment)
Great community support, active development
Seems to be lots of work to get started
Kooboo
No source activity (no updates for almost two months)
GPL licensed? (need something that allows for closed source applications)
N2CMS
Partial ASP.NET MVC support
Every customer must have a separate domain
Limited source activity (not dead but not vibrant either)
Orchard
Microsoft-sponsored (which means it's likely to be over-architected, code-bloated and slow, although it does have some well known and respected contributors/leads)
Built using ASP.NET MVC
Looks promising feature-wise (but is unlikely to be stable at this stage)
AtomSite
Feels reasonably mature and has decent documentation, albeit with holes
Built using ASP.NET MVC
Limited source activity, single developer
MojoPortal
Looks good for a portal, but probably requires custom logic to be built as modules around the product (I was hoping to avoid that kind of lock-in if possible)
DotNetNuke (DNN), CommunityServer and Microsoft Office SharePoint Server (MOSS)
Definitely not my cup of tea ;)
BlogEngine.NET
Mature and feature-complete
No ASP.NET MVC support
Integration possible but not without lots of Web.config voodoo
Not sure if it supports customer separation
Given the list above I'm leaning towards AtomSite, N2CMS, Orchard or BlogEngine.NET. If I go with the latter I'll be using jitbit AspNetForum, which is a great match for my needs.
I'd probably prefer to use a custom ASP.NET MVC solution and individual components as this is likely to give me the greatest amount of control, but on the other hand, it'll make site theming and integration harder. What combinations have you tried, what worked well and what didn't? Anything important I'm leaving out of my evaluation? Any other relevant advice?
I'd appreciate it if the answers were not simply endorsements of your favorite product or way of doing things, but something that would help me choose or eliminate solution candidates given the requirements outlined above.
With the level of requirements you've specified, I'm personally going to have to lean towards the custom approach. You can hire someone to do the design (view) portion of the site for you, or you can buy a theme off the internet from site designers and customize it to your liking. (Sometimes just having somewhere to start is enough for intermediate level customization).
Multi-site support (using a single domain for hosting)
You're probably going to want to have control of your hosting environment, either a VPS (Virtual Private Server) or a dedicated box. This is still possible on shared hosting but not reccomended.
Watertight separation of content between customers
You'd probably have to spawn a unique app-pool for each customer with thier own services user for 100% seperation.
Full integration across components/features / SSO (single-sign-on) /Single-site experience (shared header/footer, unified navigation, unified tags, etc.)
This is going to be the tricky part. This Example may have some useful insight for you in the development process, but you're going to want a unified login service and have all sites use it or link to it.
Ease of development and deployment
This is where it gets tricky. Development ease comes from your background I think. MVC is definately the right choice in this respect then, knowing a lot about the right ways of going about building a site in MVC will aid in this process. Keep up to date by reading community blogs and listening to podcasts like Hanselminutes or DotNetRocks will help keep you in touch with the newest and greatest tools/technologies for making your site get off the ground quickly and effectively.
Deployment is the tricky spot. MSDeploy still isn't quite there. But if you can you probably will want to come up with a Dev -> Staging -> Release publish structure so you can test your code in a staging (mimiced production) environment.
Custom logic will be written using C# and MVC and any products should support this
I want to stay in control
If you develop the site in ASP.NET-MVC, you'll be able to build common libraries that you can use not just in your site, but also in your custom tooling. This will greatly reduce your code duplication and helps make sure operational unity is achieved. (Everything works the same way).
Solution should offer features but otherwise stay out of the way (e.g. not force stupid idioms on me, like insisting on GUIDs for primary keys)
While you'll have control in this situation, I'd strongly reccomend GUID Primary Keys. This allows Merge Replication, which can help you easily restore backups or use failover DB servers when things go awry.
Active development community
.NET has a great community out there, (including this one) and you should get lots of support if you ask for it politely.
No single-man efforts
Not sure what you mean here, You'd be the Single-Man unless you hire help, but even 2 people can do great things given a little time. Even one-man can do great things, but the framework you're running on here is backed by a commercially funded huge team.
Recent source control activity
Doesn't really apply to .NET, but a lot of the libraries that you may use (NHibernate, MVC Contrib, AutoFac, Etc...) will have lots of activity and constantly being improved.
Reasonable levels of documentation and maturity
.NET and most of the production level libraries developed for .NET (Mentioned above) actually have a pretty good degree of documentation. There's multiple paid & non-paid sources of information for .NET alone, and most libraries (are well supported by the community and known on StackOverflow)
Does not have to be open source
Look for support libraries that are LGPL (i.e. you can use it in commercial software, but if you modify the library you have to release the new library code if you release the binary.) You're pretty safe here, your site dosen't have to be open source if you use these libraries to support your development.
Well, that's my 2cents. The project you've described is no small job, you're looking at a considerable amount of work even if you go with a pre-built solution (mainly hacking it to work the way you want). I imagine your biggest hangups would be SSO & Security for the pre-done solutions. Not to say it's impossible, just tricky and the end result may not be exactly what you're looking for.
Also, look into OpenID, it may be the best solution for linking all your sites together and most pre-built systems can easily be ported to use it.
Take another look at MojoPortal. The CMS is awesome and the main developer , Joe Audette, is very responsive. I'm have several installations of the CMS running single and multiple sites.
I would lean towards a CMS based solution. Having a tested and production ready software not only reduces the development time but also helps in continuous upgrade and reduced bug count.
If you go down this route, you may want to also consider Sitefinity. Not only does it support all the features required by you, but also is built on .NET and supports MVC development. The product is built by Telerik, the makers of UX tools.
Disclaimer: I am employed by Telerik.
I've recently come across phpFox which is a social networking/forums/community site CMS. This may be of use to you and is fairly inexpensive.
The solution for the site of our company has become EBIZ CMS: full-featured site that includes social networking, online store, features a presentation, a forum, create HTML pages and much more, including the maintenance of professional technical support, so we do not even need help for installing by a programmer, and it is only US$ 9/month!
Related
I have a company that needs a document management system.
I have looked at SharePoint but it has far to many bells and whistles. The company wants something that doesn't have intranet portals, app downloads and all the other waffle (they simple don't have the skill nor the inclination to spend thousands learning it).
I am finding that SharePoint is a little like a fork-lift bus truck car. It trying to be everything to everybody which usually ends up useless to all.
My question is does SharePoint Foundation work out of the box as a document management system or is it like an engine you put your own code upon.
The more I read through Google the more conflicting information I come across without any clear definitions.
What I want to end up with is a document management system that has authentication and a simple page / screen / whatever to link / admin to those documents.
As per usual Ill probably end up having to write my own but it would be nice to not keep re-inventing the wheel.
SharePoint definitely has a learning curve, there's no getting away from that. However you don't need to set up all the "bells and whistles" if you just want a basic DMS.
To answer your question, you don't need your own code to get a SharePoint site up and running. You will however need to spend quite a lot of time figuring out what configuration you need for your needs.
We're using SharePoint 2010 Foundation as a simple document repository in a couple of web apps and it works fine. No Wikis, no versioning, no custom pages. That stuff is availablem but we don't need it so we don't enable it. The nice thing about it is the security which hooks into AD so authentication can be set up easily and it is robust. Our DMS solutions are accessed via the internet by users, and internally by apps, and SharePoint can handle that fine by setting up alternate access mapping so that you can get to documents via internal and external URLs.
I won't lie; I've spend a lot of long days cursing SharePoint, but it's still a far better solution than what I could have come up with myself.
In case your wondering, we're using 2010 rather than 2013 because we had been using WSS 3.0 up until this year and you can't upgrade directly from WSS to 2013. But since we only need the basics, doing a second upgrade to 2013 wasn't worth the effort.
The truth is Sharepoint can be used as a sort of document management system (ish). But in truth it is far to over complicated and has gone rather off at a tangent from the demos I was original given when it first came about in the beginning. Alfresco an Nuxio are probably much better. (but even they have their issues). You simple have to look at all three and make your own decisions as now I know this is not a simple question. I personally went for Alfresco but for very exact reasons, even it has some issues but generally speaking it is the best(ish) out of the three. (Nuxio would of been best except for its 'purchase your admin interface' model.
Looking for suggestions regarding an upcoming project that I am involved in which revolves around adding certain functionality to an existing ASP.NET application running on IIS 6.0 programmed in VB.NET.
To aid in future development the client wants the additional functionality to be as future proof as possible. Ideally I have said that I would like to push for a solution using ASP.NET MVC3, running off IIs 7.5 and .NET 4, written in C#. This solution would act as a seamless addition to the current web-portal appearing probably just as an extra tabbed page.
But they will be completely separate web-apps. Which is crucial.
The main problems I can foresee are firstly sharing session particulars between the asp.net web app and the new application. Particularly with regard to maintaining session state (and not having IIS timing out on one of the apps). Also, conjoining the two "apps" appears problematic in my head, although this may be far simpler than I fear.
I'm asking for suggestions for these two problems if anyone has any ideas please say!
So far I've come up with the following solutions be they terrible or not:
1) Embed the new functionality into the existing codebase (not a great option). This would mean losing any potential future upgrade-ability and also means not following better OO conventions by utilising the MVC framework.
2) Using an iFrame to link to the razor pages of a seperate MVC3 app (the one I'm favouring currently). Allows uses of all new technologies, however downside is sharing session data. Either through iFrame "attributes" (is this possible?) through persisting a session state to a db? (slow?) or even some kind of web service interaction between the applications to push/pull user/session data?
Any advice/suggestions greatly appreciated!
I agree with you that C# and MVC is the "way to go", but unfortunately mixing two applications together is going to give you a whole bunch of headaches, not least the different session IDs. You'd probably have to have a shared database table to map them together and, as you can probably imagine already this reeks of "Band-aid".
What are the ramifications in rebuilding what is existing, in to C#? Perhaps you could suggest a complete upgrade. The client themselves seem to extol the virtues of future-proofing and therefore this would be the way to go. And no, I wouldn't promote the use of a "code-converter", but it really shouldn't be that difficult.
The next thing to consider, I guess, is "future-proof". Is the client worried that VB.NET is going to disappear any-time soon or that it cannot handle anything in the future? I find that a very unlikely scenario, honestly.
I think I've waffled on a bit, but essentially combining two applications, one with old and one with new functionality will cause a headaches. This could be solved by migrating the old site to C#/MVC, and then adding the extra functionality. True, this may seem like a large commitment today - but further on down the road, it will pay dividends.
If the current site can be upgrade to .NET 4.0 there's no reason why you wouldn't extend the existing application.
There's nothing to stop you mixing MVC and web forms (indeed there are several articles on how to do just this). There's nothing to stop you mixing VB.NET and C# (or, so far as I'm aware, to stop you doing MVC in VB.NET).
You'd have to work very hard to convince me of the merits of using iFrames. Very hard. You might be able to persuade me of the merits of running two applications side by side - with the functionality split by folder - but to be honest I'd be much happier upgrading the existing site and then building from there.
hi I am planning to develop a site very similar to http://www.nextdaypets.com/ but with some more features...i have worked on JOOMLA n i know it pretty well. but there are few limitation like access level control and there is no component available for what i need. what i m confused about is that whether i should make that component in joomla or should i develop my own cms or should i take some .net based cms and write the component for it. I know C# and .net framework as a beginner. I just completed a certification course in .net last month and i don't know php but don't have issue in learning it...so what should i do...please suggest.
Well, as i understood , all you need to do is to adopt an open source CMS (joomla or drupal) and customise it. If you know a bit of php it will take you a day of expirementing to get familiar with making components & modules for joomla /drupal. Majority of the work you can do by customising the existing stuff and using third party open source components available already. The remaining small delta amount of work, you can code yourself.IF won't be that tough i can assure.
Developing a CMS of your own might not b a good option, as it takes a lot of effort to get a stable one with all features, currently being offered.
Also , if you have a doubt about the platform, i would suggest to stick on to open source platform, rather than Commercial one. The large number of OSComponents available as well as the large community support are factors defenitly you should consider.
writing your own cms is lots of work, so you should consider this carefully. Extending an existing framework could save you a lot of time.
In your case I'd choose a cms which fits well to my purpose and uses a language I'm familar with. So if you like C#, then look for an ASP.NET based cms. Of course, if you like to learn PHP joomla would be a good choise.
Usually, when I have to pick a platform I consider a certain number of variables. For example, does your customer want an open-source or a commercial platform? Is it concerned with being dependent on you for future changes to the system? Does he have already a hosting provider? Will he host the website himself? These are all tech-questions that should be kept in consideration.
I would strongly advice against writing your own CMS. That's a lot of work, and even the best and most tested products hide some bugs. Relying on something that already exists out there, it will speed your development up, as it will allow you to focus on the specific functionalities, and not on the overall system or basic features (client-server architecture, caching, views resolving, itemization, etc. ...).
I've worked quite a lot with many CMS, and in this period my attention is focused mainly on Umbraco, a .NET-based open-source CMS that has many interesting features. I personally don't like Drupal, Joomla, Wordpress, etc.
If you (or you customer) have money to spend and can afford a commercial platform, I would suggest you to take a look at Sharepoint or Sitecore; Sitecore is somewhat conceptually close to Umbraco, whereas Sharepoint is more extensive but there is more work to do to bring it up and running.
If you are looking for an e-commerce platform and PHP doesnt scare you, you could give a try to Magento.
I hope these few names can help you. I mentioned them because of my own personal experience and - to be honest - they are all good products...
Cheers,
Gianluca.
I have been thinking of starting a site of my own for long time. I am good at all concepts of C#/ASP.NET and all DB stuff. I have created and can create a site from scratch for myself. But the effort/time involved in creating a site from scratch is little discouraging, where next thing (and more important thing) I need to worry about is the content on the site.
I have seen many sites and blogs (few links below).
I need to know, what is the general approach while creating a similar site?
Are there any general tips i need to be aware of before starting one?
http://naspinski.net
http://codeclimber.net.nz
Do you mean stating you own Blog?
you can open blog on some free service as Blogger and see how it goes.
Later you can buy you own domain name and hosting, install existing Blog engine there(even open source if you want to tweak it) and continue from there.
after comment clarification:
Buy a domain name, buy disk space and traffic from hosting company. Install ant cms(content managment system)/blog/forum/anything else you wan ton the host. Develop only the parts you can't find in existing cms/blog systems. No need to develop everything from scratch. With saved time you can take any open-source blog/cms engine and help them with patches.
Consider some open source C#/asp.net blogging platforms:
Oxite
BlogEngine.NET
Subtext
If you're talking about a blog site, there's no need to reinvent the wheel unless you just want to. There are plenty of capable blog engines in any language of your choice. Go with one and extend it if necessary.
Building your own blog engine is fast and easy. Building a good one is slow and hard. I've written many iterations of my blog - currently version 6 using ASP.NET and C#, and working on the design for version 7.
As to whether it's worth it, that's really your call. Do you code in your free time? Enjoy it? Are you willing to go through the whole lifecycle?
You will be responsible for:
Analysis & Design
Development
Testing
Deployment
Prod support
It's worth it to me. Is it worth it to you?
It really depends how much time you're willing to spend on it and what kind of site.If you want a blog site,there are a lot of free blog engine out there that you can use and takes a little time to make it live.My number one recommendation is blogengine.net...very flexible,a lot of choices for theme,and easy to set up.However, if you're like me that is willing to spend a lot of time building it then go for it.I started building my site....a social networking site(http://www.joecaps.com) December 2008 and until now I'm still building it.
I recently had my mind expanded by a new concept: Web Services for Remote Portlets, or WSRP. I learned of it during a presentation on a Java-based web portal we are considering purchasing at work; we are a .NET shop and WSRP would be the means by which we would extend this portal.
Although I cannot control the end decision as to whether or not we purchase the product, I can provide input as to how difficult it would be to build WSRP-compliant portlets. Unfortunately, my recent queries into the subject have turned up almost nill.
So I ask you, the SO community, the following: what libraries or frameworks are out there for building WSRP-compliant portlets in C#/.NET? What are some of the pros and cons of using WSRP in general?
Because there is no correct answer here, I will make this a community wiki post.
So far, I have only found the following:
WSRP Toolkit for Sharepoint by Microsoft (but requiring Sharepoint).
WSRP Portal and WSRP .NET Framework By NetUnity.
Given that WSRP is on top of SOAP, this seems like a perfect candidate for a WCF binding and channel, and yet I see nothing on the subject, anywhere.
WSRP is very contrarian. By now the world has seen that tight coupling between the data model and the presentation model is suboptimal. The success of RSS, REST, MVC, and web services in general shows this. Despite the WS in the name, WSRP stands against the core principles of Web services. The WSRP spec ignores the sound advice to keep data and presentation separate, and couples them tightly.
WSRP promises integration, at the UI level. This seems like the wrong problem to be solving.
It baffles me that this thing has lived as long as it has.
The problem it attempts to solve is often not the problem that should be solved.
If you read the WSRP spec carefully, you'll find it is a remote version of the Java Portlet Specification (if I'm spelling that right). That means that it's useful for integrating Java Portlets. Anything else will have to look like a Java Portlet, which is not very generic.
I think its popularity / adoption can be inferred by the fact that the last release from NetUnit was "This latest release adds support for Visual Studio 2005 and .NET 2.0."
I would have to agree with Cheeso. Integrating the UI with the Data only serves the portlet consumers and adds a big, unnecessary, risky layer to portlet producers. Our .NET shop has been recently forced to consider WSRP and I have found a lack of support and experience. The best MS-centric approach I have seen discussed is here. But I have not found any specific WCF implementation/support. Any leads greatly appreciated!
WSRP is essentially a portal-to-portlet web service standard. What is the primary data exchanged between portal and portlet? It's markup and largely because most portals use a web UI. This whole idea that it is not pure data versus UI is moot point. It's meant to be a web service for portlet discovery, meta data, markup, interactions, caching, portlet-to-portlet communication, etc. That's what a portal does even if not WSRP. WSRP however is an open, cross platform standard.
What is a portal that only integrates portlets from its own products and/or platform? Got Java-based PeopleSoft HR and would like to provide access to their portlets from SharePoint to your employees? Good luck. Why can't this be an achievable scenario for most enterprise software? And yes, I realize it is integration related to UI. That is one of the primary reason for why I'm using a portal. It's not like I'm expecting to get PeopleSoft integrated with SharePoint at the "pure" data level and somehow an Employee Benefits Web Part magically pops up in SharePoint ready for use. However, that is what I expect if the portlet-to-portlet integration is based on WSRP.
WSRP, although not perfect, is a superior solution in my opinion. Besides easy integration of portlet within a portal, it separates the portal from the application. No deploying of binaries to the portal server or even running on the same server. This makes sense. Never run applications on the same server as the portal server: neither will ever be upgraded. I've come to the conclusion that it's insane to put application binaries on the same server as the portal server. "Please deploy this application to the portal server and have it affect security, stability, performance, and everything in between and I would like create as many dependencies as possible and bring down the whole portal sever whenever I upgrade the application". It's a dependency nightmare. Better get a couple of portal vendor consultants to hold hands with when upgrading and to have someone to blame.
Do you need to load balance an entire portal platform when only a select number of portlets are hit the most? Portal vendors would like you to think so. A lot of the time, the portal is doing nothing more than waiting on portlets to finish processing. With WSRP, you have the flexibility to load balance portlets independently of the portal platform. It always breaks down to a few portlets that are hit the most. Why not load balance just those portlets? So instead of unnecessarily load balancing the portal on 80 CPU, you could load balance those few portlets on 10 CPUs. WSRP is also absolutely perfect for cloud computing.
WSRP is a portal-to-portlet standard. If you want to write a portlet that works in multiple portals and potentially across platforms, WSRP is it. If you are remotely contemplating integrating third party portlets, WSRP is it. It's the only standard. However, it also has some significant benefits over other proprietary local portal-to-portlet interfaces and should be considered for those benefits as well.