As you evaluate ASP.NET CMS solutions for your company, it's important to understand four key differences and how they impact your online capabilities and web experience road map.
In this blog series we'll examine these four differences, explaining why they are important to understand and what each means for your decision process. Let's kick things off with the ASP.NET Web CMS architecture model.
If you are looking for flexibility in how you build your front-end, or where you leverage your content management capabilities, then you want a CMS that has a decoupled architecture.
In a decoupled architecture the application for managing content is separate from the application delivering content. In this case, the CMS does not dictate the stack, or set of technologies required to deliver the content and website, allowing for a more flexible content delivery model. In a decoupled architecture model, content can be delivered anywhere and in any format.
In contrast, in a tightly coupled architecture web content, customer data, analytics data, website presentation, and content delivery take place in a single database and application framework. In other words, content management and content delivery are the same application.
So why does this matter?
As you build your website, you want to ensure your content displays correctly on any device or channel, so a separation of content from delivery is critical. But you may also be developing customer-facing web applications that have content you'd like managed from your CMS as well. In this case, your web application is completely separate from your CMS, so you need to know you can manage its content within the CMS and deliver it via some type of content service to the web application front-end.
In a tightly coupled architecture this is impossible to do without having everything within the CMS. So your web apps will need to be rebuilt on the CMS platform using its templates and server technology.
In addition, from an environment management perspective you will need to set up multiple instances of your CMS (application and database) for development, staging and production, requiring replication services to move application and content changes between environments. This model typically requires additional licenses for both the CMS and the database, and can be challenging to manage.
In a CMS with a decoupled architecture, you can set up multiple deployment options based on your specific needs. These include dynamic delivery using ASP.NET, multi-format delivery using mixed or different server technologies, Web Services delivery using a REST or SOAP-based API, device targeted delivery using a mobile detection system, push-based delivery such as XML, JSON, or into an external database so it can be consumed by a remote application, and plain old HTML delivery for static web content.
Your environment is easier to manage as well. Publishing Targets configured within the CMS deploy content to end-points such as staging or production web services. Bi-directional syncing keeps information up-to-date and repository services manage versions for each publishing target. This provides a very light application footprint for content delivery.
A decoupled architecture is also much easier to scale. With decoupled you can easily deploy to public clouds, content delivery networks, or platform-as-a-service solutions such as Microsoft Azure websites that provide built-in auto scaling. And because a decoupled CMS does not require a database on the web server it is generally much faster, immune from SQL injection and other denial of service threats.
Next time we'll look at the ASP.NET CMS development models available: Web Forms and MVC.
Subscribe to the Ingeniux blog for the latest in web experience management.