Hi,
So I've created a new solution for Kentico 9, following the suggested method, and truth be told, I don't get it.
I'll start by achieving our aims. We want to create an application, that is modelled nicely, but does not use the generated code of Kentico, as the idea is, that we want to encourage code reuse, possibly between CMS platforms. We want to create modules, for example, for a login page. Or a carousel.
I installed Kentico 9 locally, then I have created a new MVC solution, I have followed this guide:
https://docs.kentico.com/display/K9/Developing+sites+using+ASP.NET+MVC
And then I ran into the problem. How do you route? There's nothing in the CMS that links aliases to MVC routes, so say you select a page as a page property, how do you know where that points to? I mean, even if you can get the page from the DB using the alias/page id, how do you know what controller/action this needs to go to... Having thought about it a bit, you could write a link parser, that grabs the page, gets the page ID and formats it using a pre-existing dictionary of Controllers/actions. Seems a bit overkill if you ask me...
Also, SEO, wouldn't it make sense for the content editor to have control of Aliases/redirects? Why take this away from them? Why not keep the Kentico routing engine?
Having done a little more digging, I can now see that you use the Page ID and alias to get the page required. So I guess we would build some sort of a link parser/nav builder, that gets pages from the link/page id, and builds the link for the site using some sort of a lookup thing in the code that matches page types with controllers, right?
Overall, I think you will find that everybody will have to write these same components, and it's counter-intuitive to offer a solution that requires every user to write the same components to make it work. I believe you would really benefit from retaining routing.
I advocate the separation of the MVC application from the CMS. It's nice to have this. But, I would really like to see this having a little more context, some more integrated routing, and the return of page aliases, and more SEO related features for the content editors. I really think that you're part of the way there. I'm just concerned that if you really intend to push down the path towards this purist method of using MVC with Kentico, so far as to remove the old method of working in future versions, you will make it truly difficult to upgrade projects that have laid this method of working as their cornerstone.
I hope it makes sense. I can see workarounds for each of the issues I have raised above, it's just that I'm not sure we should have to work around.
Thanks,
Gabor