MVC and Kentico CMS

I am actually sort of on the way two write two blog posts in following weeks or months (depending on my other priorities):

1) How to convert Kentico to web application project (with 5.5, it is quite simple)

2) How to use MVC based pages within it (if this would be technically possible but so far it seems like it is doable to me)

If I succeed with both, 6.0 should officially support this approach.

pointless arguing... saying that Kentico is MVC is the same abuse, that Microsoft does, saying that simple webform page is a MVC pattern implementation, lord, forgive them, for they know not what they do ;) check it out here http://msdn.microsoft.com/en-us/library/ff647462.aspx I wander why MS did not remove this article, but linked it to ASP.NET MVC framework:) nevertheless...

I understand point made by Martin H., on some high logical level you could say, what you said in your article... and what MS said but make sure you mark this statement with big " "... and ;-) and :-D

Kentico is not an MVC pattern implementation in programmers world, why? because it is not a framework like ASP.NET MVC (frameworks are meant for developers). A target of Kentico is not a highly skilled C# developer, a target of this is a person with basic HTML/WWW knowledge, and an idea what he wants to accomplish, a person who wants to build a simple site, and maintaining it later with little effort, witch is not so expensive as its development of highly sophisticated custom software solution.

off course you can extend it with help of a developer, but he cant use MVC framework to do this, he has to use webforms with MVP pattern for example, if he wants to have a testability, separation of layers etc... or he can do all stuff he wants in event handler placed in codebehind... there's neither conventions nor rules to obey, sky is the limit:)

Specifically for the stylesheets and scripts you can very well use the web part Head HTML code to include such code for on specific templates.

I got your point with header / content / footer, currently we recommend to just encapsulate each of them into standalone user control ... which in the end you develop and it acts the same way like ASPX code directly on the page.

Could you somehow propose how this should look like in the admin UI (from the page template selection and layout editing perspective?)

Hi,
One example would be where you have in aspx multiple master pages. WHere you for example define modal pages with a blank.master (without chrome) and other pages with a default.master (with chrome) and both of them inherit from a global.master which includes base stylesheets, scripts etc. Then you might want a master page for a specific section (say a Suppliers.master for a special supplier seciton) which has say 2 or 3 content placeholder regions to be overridden by child pages within that section but otherwise have a fixed section specific chrome.

With the portal engine, we have one master page. IF we create a page template that uses that master page, we can only define 1 placeholder. THis means there is only 1 region of the page we can override. We commonly allow for head (stylesheets), content main (within body) and scripts (just above the body) to be overridable so we can't have the limitation of just one are of the page being overridable, it's just not flexible enough.

We are currently using portal engine to make use of widgets and are finding that whilst we are getting some re-use with the page layouts, we are creating individual page templates for each page and manually placing user control web parts around the page templates to make the pages consistent whilst having the flexibility to alter the pages as required. The template inheritance model feels too rigid where you have to inherit all content from a particular level.

Essentially we want the functionality of aspx master pages replcated within the portal engine as is, as it's a great model!

One last point would be that we would like to put a user control reference in the portal engine head area (As we are mixing aspx and portal engine) but we have to manually copy our stylesheets from a global stylesheets user control rather than link the user control which isn't ideal.

Hi Keith,

True, we have spent a lot of time on modules but the document API stayed pretty much the way it was in times of 1.x. We plan to definitely improve it in next versions. Same for the support of widgets (actually entire portal engine) in ASPX. Supporting more placeholders is more complicated since the document is assigned with a single template which has single layout, so changing this to many some way might be just too complicated for the beginners.

If you could provide us with some sketches of how your web site structure looks (works) like and details on what was too much for portal engine, it would be great. I agree that we should somehow support it but I need some real-world feedback for that to know the exact needs to make that happen.

I found this thread very interesting. I don't think any of us should try and pretend that Kentico, architecturally speaking, is currently that strong. Kenticos strengths are in the flexibility it affords devcelopers with custom document types, workflow and permissioning which would otherwise take a lot of time to develop from scratch.

Like Michiel, we too have developed a strongly typed, reflection based business library for working across TreeHelper and DOcumentHelper to make our larger Kentico applications more intuitive and maintainable. I hope to share this on Marketplace soon.

It does things like automatically load strongly typed entites from wildcard aliases, and choose whether to use DocumentHelper/TreeHelper depending on properties that have been set on 'criteria' objects. IN short, an object orientated repository/specification approach for working with documents.

My general feeling is that too much time has been spent developing satellite modules and functionality rather than on the core CMS engine. Version 5.0 is nice in that it has been an attempt to focus on performnce issues.

I believe that Kentico should focus on providing a more coherent set of apis as there are many missing best practices as Michiel has pointed out.

As much as rewriting the internals of the system, developers need consistency and ease of implementation, not 10 ways to do the same thing, and a lot of jumping through hoops as soon as you leave the portal engine.

OH, and on the portal engine, i totally agree with Michiel. One page placeholder? Why not 3 or 4. One master page? Crazy! We just couldn't build any of our sites with that even if we wanted to. We're implementing widgets with portal pages and mixing it up with aspx, but only because we HAVE TO, because Kentico didn't provide support for aspx and widgets in v5.0.

I still really like the product, but the apis are a bit of a black art at times.

Hi Dmitry,

Read my comments above for Michiel. You can very well work with the code from CMS under source control, there is no limitation. We are planning on further integration directly with VS so you can browse and manage the objects directly from VS.

But still, you should not think PAGES, you should think COMPONENTS. Develop a web part and then let your designers to insert it through design mode. Think about Kentico CMS as your IDE, you don't even need to open VS unless you need to write your custom code (which still should be a reusable component, not a page).

I mean, the whole CMS thing is about making such modifications easy for end users, otherwise, you would not need CMS at all and you can develop everything from scratch.

I wonder how you can make such statements about Portal engine and Web parts if you are clearly missing the point here (based on your numbered statements above).

No, I am completely serious, there is no need to make ASPX templates if your web site is correctly component based. These components can be always be included within web parts.

1) We parts are pretty standard user controls (just inherited from special class), where do you see the problems? The only difference is that portal page loads the controls dynamically. Otherwise, it is still standard ASPX page.

2) No way! If you copy-paste you code from ASPX template and put it to web part, you get exactly the same functionality. Of course if your code is separable enough as a component and not anti-pattern ;-)

3) Same here, just use webpart instead of the second and other placeholders, you get the same functionality

4) You just need to know where it is, it is not that complicated to know and it is closely tied to the visual representation. Read the tutorial is enough to learn the basics

5) Again, what do you see as better option and why you cannot use it with Kentico, I asked before and didn't get any answer from you ...

6) It does, the transformation is very closely tied to the document model since you are typically evaluating the fields from it

7) Check-out all such objects to the disk and you can maintain them in VS including version control. We are however planning our own mechanisms for their versioning in DB

8) Go to the site settings and disable it, it will be done automatically for you with no locking

9) True but you can leave them checked out even for the build. Besides, getting them from DB to disk is just few lines of code that you can incorporate in some of your pages or console app, see the button handler and let the build process call the page or console app

10) Other products usually do not even have such feature. Number of bugs is based on its complexity, it is quite hard to maintain it across versions. It is not uncommon that software has bugs and we do not have that many compared to competition

11) Could you elaborate on this a little more? Possibly give some specific examples of what exactly you would like to do and why you can't

I strongly recommend you to go through the details in the entire Developer's Guide, it feels to me you stick up to some of your previous knowledge not accepting that things can be done different way than you are used to. Otherwise I cannot see how you could possibly think of this as a joke. Direct ASPX page development is many years old, it is time to move to newer and more efficient ways even that it may make you not being guru at the start (since there is not that much you need to know about it).

I agree with Michiel and I understand that your try implement some kind of a declarative way to design and maintain of layout but this way suitable only for minor changes but fully not applicable for initial process of design and development.

As I said above, customers wants easy way to maintaining of his product, but developers need flexibility into development process. They do not want use any kind of web based IDE such as CmsDesk, when they have standalone IDE.

For example, developers cannot work with same page without source control.

[quote]
"Personally I don't like the ASPX template model and I always recommend Portal. We maintain it mainly for historical reasons and for the reasons that it looks that developers had to do some coding even when they don't which looks better to their bosses and make them more valuable :-)."
[/quote]

I really hope that was a joke... There are so many reasons NOT to use Portal Mode, that your statement is not even funny.

1. Existing ASp.NET skill not applicable.
2. Content inheritance tied to conten tree depth.
3. Single page placeholder is very limited.
4. Hard to maintain with mark-up stored everywhere.
5. Transformation is the complete anti-patterns of separation of concerns.
6. Coupling of transformations to document types makes no sense.
7. Storing code in database makes versioning impossible.
8. Check-in and check-out is a locking workflow, unlike modern SCM systems.
9. Automated build too complex with code in database. Tools exist to integrate all mainstream SCM systems, none for Kentico.
10. Content staging has too many bugs to be realiable for deployment of code.
11. No way to write custom base classes, code-behind or implement any custom way of building a site.


If you are serious that ASPX mode is maintained for historical reasons then I don't really know what to say here...

And again, Kentico is not even close to MVC. That includes the Portal Mode. The most important aspects are the PageManager and WebParts which are in no way in accordance with MVC.

Today, the term 'MVC' will be associated with what you see in ASP.NET MVC. Serious ASPX developers will not buy that Kentico 'is MVC' or 'follows MVC' because they find no such evidence in the current templating solution. Sorry.

Agreed. We are working on it :-) It just takes time so please be patient.

I voted for MVC not realizing at that moment that it's not the best fit for Kentico. But even then, a vote for MVC is also a vote for a better architecture with better separation of concerns and testability, which is not a bad thing for Kentico.

Well, in such case you would be back at the ASPX model where you can do all these things the way you wish but your designers have to struggle with VS, too. Our portal engine and design mode give our solution unique value which really boosts the development process of a typical web site to the point where some of our clients produce a complete web site once a week or two (each with it's own templates).

Good news is that with 5.5, you will be able to use portal engine (web part zones etc.) even with ASPX template which will really enhance the options and makes it more flexible for everyone.

Personally I don't like the ASPX template model and I always recommend Portal. We maintain it mainly for historical reasons and for the reasons that it looks that developers had to do some coding even when they don't which looks better to their bosses and make them more valuable :-). I believe you can do the same things in both, you just use different approach ... Web parts are great example of standalone components that can be developed and tested separately and then used by anybody.

Could you give me an example of what had to be done with ASPX templates and couldn't be done with Portal engine in your projects? What exactly is so complex collaboration that needs to be done control-to-control (or page-to-page) in ASPX model and cannot be done the same way webpart-to-webpart in Portal engine?

I agree that our solution is not yet really ready for unit tests and honestly, I don't like it too, but it is a long process to make that available. You may not reuse some of your previous experiences when you start with Kentico, but after you get used to it, you quickly get the time spent on learning it back. Don't just take my word on it, search the web on user's opinions and comparison with other solutions, let the people's experience speak.

Ok,
But in a real world, developers prefered using Visual Studio instead of CMS to developing and designing his solutions.

For instance, using MSFT MVC or Sitefinity CMS developers have ability to use VS. And MSFT MVC framework provides ability to test url routing engine separetly from other parts of solution. In order Kentico more flexibility only when portal engine is used.

So, Kentico is more applicable for a small sites which contains blogs, forums and do not have complex logic of collaboration between them.

Not so long ago, my team started develop solution which should be builds on a Kentico CMS and from first minutes we have problems with CMS. The main issues is that we cannot use our previous team experience starting from setup dev. enviroment and finishing design a unit tests. Our designers not able to do his work independently from developers because they expect that developers will be use portal engine but in a same time developers expect using ASPX templates.

Of cause, developers would be able to use portal engine, but do checkout each page and then commit is not good way. I just try to say that Kentico not suitable for agile development, test-driven development and so on.

As a result customers expect from developers solution with which they will be able to work without any additional development process. They expecting using CMSDesk to add additional functionality. But developers according to requirments do not have ability implement these requirments without using portal engine which do not provide flexibility into development process.

As instance in the Sitefinity, Telerik implemented this feature. They provides something like a master page with different types of placeholders. And their CMS have ability to work with templates from web site and from VS.

Hi,

Here is an analogy for the Portal engine of Kentico CMS:

PortalManager control together with the PortalEngine library and URLRewriter is the Controller which handles all actions and distributes the data from page templates to the web parts

Templates themselves, the web parts and transformations are views

And the data classes and data behind it is the model.

As I said, it is not a pure MVC. There is no such pattern regarding the admin UI in place but what you do when you implement the web sites is working and integrating with the portal engine most of the time. For ASPX templates and your own custom pages, it is up to you how you implement it, there are no restrictions to your code so they are out of the discussion.

Ok, MVC is a good pattern, but primary goal of MVC is to provide a better ability for unit testing. You saying about Kentico like as MVC pattern implementation. So, if the Kentico really implements MVC then how developers should perform unit testing? I say "developers" because the Kentico's design, do not provide ability to work within a developers team.

And so, please tell me how developers should work with controllers without views?

1) It fits if you make it that way and divide the View and Controller further into logic layers (that is what you get if you change your application from 3-tier to MVC the easiest possible way). It is easier to go from 3-tier to MVC than backwards from this perspective.

2) That is what we plan, there is no reason to switch to pure MVC. Still I am not sure why you voted for it if you don't want it :-)

3) Portal engine is much closer to MVC than ASPX model. Still, it is a hybrid as I wrote before, that doesn't mean some of our patterns are not MVC-like. If you create a pure MVC application and then add one standard WebForms page to monitor it, would you say you followed MVC pattern?

4) Is there any specific reason for it? How will the ASP.NET Routing look online into our database to see what is correct to route and how?

5) There is no need for it, we know what to do, we just have other priorities needed to be done first. Still, if you miss something there, let us know as always.

1. Where does MVC fit into the 'standard' 3-tier architecture?

Sure, the controller can implement business logic, but is that a good choice? How much code would a Document controller have if it implemented workflow logic? In a complex system like Kentico the controller would not implement this kind of logic. So ideally there would be a separate business logic layer between the controller and the data access layer. As such my point that in MVC the View+Controller are part of the Presentation layer is more valid in the context of kentico CMS.



2. Motives of Microsoft for releasing the MVC framework:

I must reiterate that there is NO "switch" to MVC from Microsoft. MVC is the 'second' framework for building web applications. But second only in terms of release, not in terms of quality or preferred choice, that is up to the user. Scott Guthrie and Hanselman make lots of effort to make this clear as well. WebForms is not 'wrong', MVC is not 'right'.

This is also why I hope that Kentico will focus on WebForms patterns, and don't focus on MVC. At least for the near future (1-2) years. Because there are lots of patterns possible with WebForms that are not explored at all by Kentico.



3. Regarding your statement that Kentico CMS follow the MVC pattern

I am still amazed... it does not. All my points were to underscore why it doesn't. I understand why it works this way, it doesn't matter. What matters is that Kentico CMS is NOT an MVC application, and APSX template developers like me are not developing Views on top of Controllers. Our ASPX templates are the request handler. So no, it's not a controller. And the static properties on CMSContext is not a View Model.

Maybe you feel that the work that is done by Kentico before control is given to the ASPX template is somehow a controller. Even then, there is no way to inject into that controller anything. There is interface to implement, no base class to inherit from, no way to implement my own controller, no controllers or subviews for any related data like polls or bizforms.

So to conclude this point: even IF we stretch the definition of MVC until Kentico CMS matches it, that has no value for ASPX template developers. They can't use it like they can a true ASP.NET MVC application (or a Castle MonoRail based application).



4. Combining existing MVC application with Kentico CMS

Here you could make improvements by switching your routing implementation to ASP.NET Routing (System.Web.Routing).



5. About Kentico API

If you want my advice I can do an analysis based on official framework design guidelines. But like your company charges for consultancy, so do I (no cure no pay). If you are interested you know where to contact me...

Hi Steve,

What you say is true, but this article is about MVC as an architectural pattern, not about specific implementation.

So MVC in general and ASP.NET MVC Framework are two different things ... i described it in the article

Yes, it is a hybrid because not everything here can be done with pure MVC that easily. But that would be the same discussion as about whether Windows is operating system when it contains Paint, which is not something that operating system must have :-)

I expect Michiel will reply for himself, but I wanted to comment on the point:

[ "The fact that we use server controls that fetch data should be a clear indication that we are not dealing with an MVC pattern in our templates." /// How else the controls should get their data? You are not dealing only with current document but with any data from the entire project ... ]

MVC doesn't use server controls (runat="server"), so if you are using them, it's not MVC! All the data a View needs is provided by a Controller (in Microsoft's framework, either explicitly in a Model object, or ViewData dictionary).

(OK, you can use server controls in MVC, but this would then be a hybrid of MVC & WebForms).

If anyone wants a really clear introduction to Microsoft's MVC Framework, I'd recommend the book, "Pro ASP.NET MVC Framework" by Steven Sanderson. The current book edition is for MVC V1.0 (note that V2.0 of the framework is due out at the same time as .NET 4 in a few months time).

Steve

Hi Michiel,

"Controller is certainly NOT the business logic layer." /// With MVC pattern, it is allowed that controller uses Data layer directly so it makes part of the controller the Bussiness layer code (in fact Business layer must not have been so clearly separated).

"In ASP.NET the Model has no standard implementation." /// I never said that. It just guides you with the pattern. MVC application can be done very well even without ASP.NET MVC Framework.

"Under no circumstance is MVC meant to make right a previous wrong architecture." /// If their previous architecture would be correct (no matter if Forms, MVP or anything), why would they even bother to switch to MVC? There wouldn't be a reason for it, would be? I was just putting that specific situation to right words. :-)

"The fact that we use server controls that fetch data should be a clear indication that we are not dealing with an MVC pattern in our templates." /// How else the controls should get their data? You are not dealing only with current document but with any data from the entire project ...

"You should make it clear that the choice of Kentico is (for the near future) also a choice for WebForms." /// Yes it is, I think everyone who installs the trial version can see it at a first sight, it should be clear. However there shouldn't be a problem to combine existing MVC projects with Kentico CMS as I said i my previous comment.

"That should be NO reason for Kentico to support it in my honest opinion." /// That is exactly what this post was about. It is not needed ...

"It is highly inconsistent, does not follow standard naming conventions, implements events completely wrong from a .NET point of view" /// I think the only .NET convention we are not following currently is the local variable under a property (that is for historical reasons), could you give us some examples of others? I agree the events are mess and we plan to make it better. Fortunately for me, this is a leftover from times I wasn't able to influence this so I am not responsible for that. Same for the document API, it is too general (partially based on the fact that the document types are defined from UI, not from code), but we can do better. Other APIs around objects is OK I believe, do you have different feelings (what in particular?).

"is totally interdependant to the point that for one method call you may have to reference 6 or 7 assemblies, and is 100% impossible to unit test or mock." /// That is mostly to centralize the code so if you modify it, you need to modify it only in one place and DLLs to not get too big. Also, with Staging, Web farm support and abstract data model there is no other way. Yes, is is not the right fit for Unit testing or mocking, but that is something that wasn't present in .NET at the time this was designed ... so again, historical reasons.

"The reliance on just a few provider methods to retrieve data ..." /// True, that is the same case as with the document API, we will improve it. LINQ by default is not possible just for the fact that we still need to support .NET 2.0 but we plan it for future. Also, the object model is not yet ready for it (it was designed before the LINQ was introduced).

"who have to do crazy tricks to get around the stupid idea of transformations" /// What would you like to see instead of transformations? Is that something you cannot do now? What is exactly what you need to get around and cannot do without tricks? I believe you are just misinterpreting our guides and do the things in a more complicated way than it is needed.

"The amount of files and code is immense." /// I explained this sometimes before. We could have all code in libraries but that way, you would just have to implement ever smaller changes from scratch. On a development machine when you are fixing the defect, you may still usually test it under dynamic compilation so it is not an issue and how often do you precompile and publish the project for QA or release? Once a day? Once a week? These 15 minutes do not require any user assistance, it can be automated and done on any machines so in the meantime, everyone else can continue working. There is no need to compile the web project if you debug the class library, you can do it under dynamic compilation as well and disable the web site compilation under debug in the Solution properties.

"Sure, I have voted for the MVC support on the UserVoice site (gave it 3 votes too)." /// We know :-) and we still count is as one for each such case so it is just. So there is no need for anyone to vote more than once. If that particular thing is crucial for you, just add it to the comment and explain details.

"I have just opened a new request, that you can find here" /// Yes, this is the right way to go. The fact is that we are somehow still bound with some original patterns from version 1.x, 2.x etc. due to backwards compatibility, it started with .NET 1.1, now we still have to support 2.0 so the changes cannot be done as easily as it seems. We could make each version use different patterns and the newest .NET features, but that way each upgrade would just become nightmare, we cannot afford that ... Imagine that we completely rewrite Kentico in 2012 because some other clients needs to support some great feature from .NET 5.0. For you, it would mean to go completely different way and rewrite all your code? Is that what you would wanted? I don't think so ... As a software platform, we are in the same situation as Windows who has to support 32 bit apps in 64 bit OS, .NET which has to support Forms instead of requiring only WPF etc.

I hope I responded to all your concerns, if not, let me know.

Hi Steve,

From the URL Rewriting perspective, the pages handled by MVC would be just another excluded URLs in the site settings, the same way you create your custom system pages in a standard way. So I don't see why MVC and our URL rewriting couldn't coexist (unless there is no way how to allow MVC ignore URL patterns not processed by it and let them process normally)

You are right that Kentico CMS can be easily converted to Web application so this shouldn't be a problem too.

I suggest you try to combine your app with Kentico and let us know if you have any issues with it.

Oh wow, I don't know where to start... This post presents a great misunderstanding of the MVC pattern in particular, as well as (web)application architecture in general.



About the standard 3-tier architecture and MVC:

First of all, it is not a "different look on the standard 3-tier architecture". MVC is only a pattern for separating logic from presentation. So IF you use a standard 3-tier architecture, then the View + Controller in MVC would form the presentation layer. So the Controller is certainly NOT the business logic layer.

In ASP.NET the Model has no standard implementation, it is left to the developer to choose a pattern and implementation. Examples would be the Record Set pattern using Microsoft Typed DataSets, the Active Record pattern using Subsonic, or the POCO pattern using something like NHibernate. In some of these patterns, the Model part of MVC is capable of retrieving and saving data, so it can be said to implement the data layer of the standard 3-tier architecture. In other cases (like the POCO example), you would need a separate data layer to retrieve and save the Models (using NHibernate and it's ISession object for instance). So the Model part of MVC is not entirely focussed, you can go many directions with it.



A minor issue with the marketing statement:

Under no circumstance is MVC meant to make right a previous wrong architecture. It's an extra choice, WebForms is not wrong in any way, in fact it is still evolving with more features. A competent programmer can use WebForms with the right patterns (MVP for example, I will come to that later) and create a beatiful and 'right' architecture. But as it is, MVC has become a bit of a buzz-word.



About Kentico CMS and MVC:

Kentico CMS most certainly does NOT follow the MVC pattern! There are no Controllers for any Model. That I have access to the node associated with the current request through some static methods or by fetching it from the HttpContext is not in accordance with the MVC pattern.
If I create a custom document type, there is not a Model of that document type loaded and passed into my View. There is no controller that I can test stand-alone from the database (one of the most important things about the ASP.NET MVC framework in my opinion).
CMSContext is not a controller and the data it exposes is not a model. The fact that we use server controls that fetch data should be a clear indication that we are not dealing with an MVC pattern in our templates.



About customer feedback, some of our experience:

Currently we are developing a separate class library that hides the often confusing and very inconsistent API behind a simple and easy to use API. I have said it before on UserVoice, the Kentico API is an absolute mess.

• It is highly inconsistent, does not follow standard naming conventions, implements events completely wrong from a .NET point of view, is totally interdependant to the point that for one method call you may have to reference 6 or 7 assemblies, and is 100% impossible to unit test or mock.

• The way that web parts are implemented is with almost no regard to ASPX developers, who have to do crazy tricks to get around the stupid idea of transformations, and which have complete CMS logic built into button_click handlers, something even intermediate level WebForms programmers learn not do.

• The reliance on just a few provider methods to retrieve data means that we are forced to sometimes use overloaded methods with up to 15 arguments, just because we need to specify orderBy, which is the last argument in the list of that one overload. It also means that in many cases we are writing SQL in strings in our codebehind to filter some data (try fetching documents in a category for instance). At that point, we have lost all possibility of abstraction, we are just coding straight to the database! This is in complete disregard of the current developments in .NET, where data access is supposed to be abstracted for us by LINQ
(I am working on a LINQ to Kentico implementation if you're interested give me a call)

• The amount of files and code is immense. Our precompilation takes about 15 minutes. That's quite an impact on our agility in fixing run-time defects in compiled code. It also means huge start-up delays when debugging a class library. The total lack of an actual plugin architecture means that there is really no way to slim the installation down, although it helps to deselect the example sites.


It's not all negative:

There's a positive side too. Kentico CMS still allows us to develop great websites with many cool features, like navigation, workflow, tags and great search using Lucene. It's just that the code we have to write as ASPX developers to work with the system could and should be a lot easier.


To conclude:

I have mentioned that MVC is very popular (lot's of buzz on blogs and Twitter). That should be NO reason for Kentico to support it in my honest opinion. You should make it clear that the choice of Kentico is (for the near future) also a choice for WebForms.

Sure, I have voted for the MVC support on the UserVoice site (gave it 3 votes too). But I have a better idea... I have just opened a new request, that you can find here:

http://kentico.uservoice.com/pages/33767-general-suggestions/suggestions/439523-webforms-based-patterns-like-mvp-

It is a request to focus on patterns that are currently available for WebForms developers. As such it represents an opportunity for short-term improvement without reachitecting the whole CMS.

I do agree that Kentico has some of the characteristics of MVC, but in at least two important ways it is not pure MVC:

- MVC mirrors HTTP's stateless nature, whereas a WebForms application (like Kentico) is stateful & uses ViewState, postbacks, event handlers, etc.

- MVC allows you to completely separate the layers, so that you can run automated unit tests on everything, apart from the (very simple) View layer (using dependency injection & a mocking tool, as required).

However, I like Kentico's architecture - so perhaps I'm just being pedantic.

But you asked for practical examples of now an MVC application would need to integrate with Kentico.

I am writing a booking system using Microsoft's MVC framework. In the future, I may want to display the booking system pages within Kentico.

The most immediate question this raises, is how will the Kentico URL rewriting engine & the MVC routing engine (System.Web.Routing) work together? Will they just run one after the other in the request pipeline, so as long as the URL is valid in Kentico or the MVC application, it will be handled?

The other issue is that Kentico is a "web site" and Microsoft's MVC is a "web application" (with respect to the way they are compiled in .NET). I've read a post elsewhere on this site that says Kentico can be compiled as a web application, so hopefully this would not be a problem.

Hope this is useful feedback.

Steve