Quality of Kentico CMS source code
Hi there! I found a moment in my busy schedule to post one more article. This one will give you an overview on what you can expect from our code and also reasons why you may want to buy our Source code license. If you are interested, read further ...
Our customers often ask about quality of our code and what they can get if they buy the source code license. Obviously, you cannot get the whole source code to see before you buy the licence and you are entitled to it. For that reason I want you to give a little sneak-peak of segments of our code so you can decide better.
A little of boring history facts ...
As always, I will be completely honest with you so I must start with something about previous versions. If you already know our code from previous version, so you may compare.
Would I use Kentico CMS for my project?
- Version 1.x - When our company started 4 years ago, it was a company of one man. As you may expect, there had to be something which was wrong. Because when you start a business, you cannot just say "this is going to be great" without having the exact idea of what will happen in future. The bad thing about version 1 was the architecture. It just wasn't scalable enough and as the company grew, some of the parts were written by the external developers, which became problematic by means of not enough control over their work. They were under contracts for specific modules and it was very hard to give them their work back and meet the deadlines in time. I personally joined the company at the time of version 1.7 where it slowly became obvious that it cannot go that way for a long time. This is the problem of every virtual company and also free open source solutions build by standalone programmers, even if you have detailed rules, you cannot just control everything. One day, it just becomes too chaotic that it cannot be controlled. So honestly, I'd like to give you one advice here to help you avoid sleepless nights: Do not use free open source solutions or products of virtual companies in the projects, which you want to be good, because it can be a nightmare for you! One way or another, we had to deal with these things for some time, until we decided that this must be changed in order to make our product good enough for you, our customers, and it was the exact time to move to version 2 leaving all bad code behind.
- Version 2.x - New version 2 had completely revised architecture, making the solution more scalable and friendly for the end users. What I like about it most and consider groudbreaking was the code. At that time we became quite recognized by the market, we could afford to split our employees into specific departments and become the company with new great office where everybody had his place and where we didn't need any external programmers anymore. The result was obvious, we had much more control of our code, and we were able to react to the problems in a real time, solving most of them at the moment they raised. This significantly improved our code experience, making it worth it for professionals like you. If I should give the code 1 to 10 where 10 is best, I would probably give 4 to version 1.x and 7 to version 2.x. Why 7? Why not more? Well ... at that time I would give more, but as we become more experienced, we also become more ambitious and of course we are still improving it, that's why. So the version 2.x had nice architecture, pretty nice coding, where is the catch? Actually, nowhere, with version 2.x our product became so nice, that so far no next version needed significant revision of the whole solution. See how great deal can bring you when you change from virtual company to an organized office? OK, so why next numbers?
- Version 3.x - As I mentioned, version could easily continue with existing architecture so the numbering wasn't really the most important thing. You are right, the numbering is more about marketing and pricing. At certain points, we bring so many new or significant features to our solution that we must change the licensing or we just thing it is better for you to have clearly staged experience about versioning. 3.1 is better than stick with 2.83 or so, right? Also from your point of view, you are already getting a third generation of the product, which is obviously better than the first or the second. With new version, there usually also comes the time for management to meet and discuss the processes, optimize the working process and other things so it also gives you the idea on how we are getting better in what we do. From the coding perspective, the version 3.x is being optimized for performance (effective code) and as there is more and more developers in our company, the coding rules are getting more precise and better. I would give 9 points to our current version just for the reason that there is some code left which wasn't revised enough, but we are working on it, believe me.
- Next versions - Of course my goal as the CTO is to believe that our code has 10 points from 10, we are working on it very hard, revising the modules one after another. It takes some time because in the meantime we of course implement new features which also must be revised, but the progress is good and we are getting close to finish it.
Well, that's the question ... I know all the code and modules of our system and I am also sort of perfectionist so I am very strict to every part of the solution I would possibly want to use, most of you would probably have lower requirements.
I would certainly use the version 1.0 to 1.8 to a smaller project, mostly because of its pricing at that time. I wouldn't however use it for larger projects. I would probably use version 1.9 for larger web sites, again, because the pricing was cool. But choosing the product just for the reason of price isn't the right thing, right?
Version 2.x was kind of cool from the start, having only some difficulties with the performance. I would use it for a smaller to medium project because the advantages of it were great for such price and it had really nice features. I wouldn't choose it for large project only for performance reasons if I wouldn't have my own servers or web farm.
I would definitely choose version 3.x, mainly 3.1a for my project of any standard size, because it kept all the great features and also solved the performance issues from previous versions, so my final answer is YES!
it is great product for a decent price and it gets better every day.
Let's get to the point! ... Current quality of the code
First something about how our code is structured:
- Libraries - We carefully divide the classes into libraries which may seem just too complicated to you, but on the other hand, gives you the reason why you should believe that the architecture is great. Every library has its purpose, grouping together the functionality of certain features or module. Every library also has its own namespace so that is clear where the classes belong. Our namespaces and library names always begin with "CMS." e.g. CMS.SiteProvider.dll and CMS.SiteProvider.
- Classes - The classes are divided into several types, there are:
- Info classes - e.g. UserInfo, which are API containers for the database records, encapsulating the data to the object.
- Info providers - Managing code for the Info class data is stored in the provider class, which handles all the basic operations with the objects
- Helpers or Utility classes - Helper classes usually provide grouped operations or general methods for data transformation or preparation. There is also one helper library GlobalHelper useful for the general operations not exactly connected to our CMS.
- Other classes - Special cases require special classes, which cannot be just categorized.
- Enumerations - For better programmer experience, there are of course enumerations in the cases user can choose only from certain values.
- Constants - Important values are provided by the constants.
- Controls - There are several libraries of server controls, structured by their purpose and need of references to other libraries.
- Pages - Pages are carefully structured by their purpose, which gets even better with new version, directing to separable modules. Reused parts of the pages are implemented by the user controls so the code does not repeat too much.
- References - There are always only references to the libraries which are absolutely necessary for the library. This gets even better in upcoming version where we are clarifying what depends on what.
You can see this is a pretty standard way how the project is structured, we carefully maintain the structure and everything must be approved. Now something about the code itself:
- Namespaces - As I mentioned before, all our library code is strictly divided into namespaces starting with "CMS."
- Standalone class files - Every class has its own file in the solution structure, somewhere we use folders for better orientation. Only some enumerations or delegates are included into common files to keep the number of the files low.
- Naming conventions - Everything has its naming conventions: All our libraries, namespaces, classes, names, property and local variables, constants, method parameters, methods, CSS classes, resource strings, file names, icon names, enumerations, control IDs etc.
- Code constructions - We always use brackets in conditions even when there is just one command, it helps avoiding the mistakes when you update the code. We also use brackets in all conditions to clearly specify the priority of operations.
- Comments - Every public member and also non-obvious non-private member is properly commented. Also the processing code is heavily commented explaining the process. There are also internal rules on how to write comments.
- Regions - Most of the code uses regions to separate the members by their type for better orientation.
- Warnings - All our libraries are compiled with warning level 4 without warnings and signed with strong names, you get the key for signature with the source code license.
- Data access - All data access from our code is done through our data layer, which is strictly required, otherwise you wouldn't be able to use you own data providers, right?
- CSS and design - Of course we have some rules for the design and CSS.
You can see that we have a lot of rules how to write our code, all this has two main reasons, first is to provide you the experience
that the code "IS WRITTEN BY SINGLE PROGRAMMER"
and "IF YOU UNDERSTAND ONE LIBRARY, YOU UNDERSTAND THEM ALL"
. This is basically our main goal.
Just to not forget to mention anything, I should mention that we use Team Foundation Server as our Source Control provider, just so you can see that the code isn't populated randomly and the process is organized. We used Visual Source Safe but as our project grew, it became just too slow for us.
Our typical process of development is following:
- The developer creates the class / page / control following the Design pattern. Yes, the design patterns are important part of our solution and if you are creating some larger project, I recommend you to at least read about how it works, you will like it.
- Then he implements everything which is on the top of the design pattern, which is special.
- He reviews his code and functionality of it, and corrects what doesn't match the rules
- The technical leader reviews his work and code, ensuring everything is correct and the module is working properly and efficiently.
- The CTO (me) reviews the module to see if it matches the requirements and can be delivered to the end customer.
- QA department takes care about detailed testing of the features, performs the predefined test suites of every module, returning back anything that is wrong.
You can see both code and functionality is checked multiple times, to ensure proper effectiveness and functionality. Again, this is something you can never expect from a disorganized, open source community, the great deal of commercial product
Do you want to see some code?
Of course you do, who wouldn't? :-) I'll just post here one of our very simple provider and info code, basically, this is the concept every provider uses this one is done clearly by our design patterns, with no special methods. It is just for you to decide how organized the code is.
You can see the code of user interface by installing the trial or free version, so I do not post here any of these. See for yourself.
What you get if you buy the Source code version and what you get if you buy standard version?
With standard version, regardless of whether it is trial or free, you get all the code of administration interface, that's basically the web project which is installed on your machine. You also get the full documentation and code samples. We want to give you as much information as we can, it is always better. With this standard version, you need to keep our DLLs and cannot change the default behavior of our Application and Data layers ... well that's not completely true, you can, but only through placed where we introduce the ability for customization, you can find the details on customization in our Developer's guide.
On the other hand, if you buy source code license
, it gives you many advantages:
- You can create hotfixes and change the default behavior of the providers by yourself so you don't need to wait for a new version to come out.
- You can add your own, additional functionality to the providers.
- You can let your experts analyze the code to be sure it really satisfies all your security requirements.
- You can compile the project against any 3rd party components or make it compatible with it without waiting for new version.
- You can get better understanding of the processes behind the UI and get more effective in what you do.
- You can debug the code in our libraries to see why your code isn't working, what you forgot.
- The source code version is fully functional project so you may run and install the database directly from the package of the source code you get from us.
And of course, you get the source code with each version until your subscription is valid, so you can directly compare what is new in the code in the new version in most advanced details.
For the experienced users and the partners who deliver sites to their customers on a regular basis, I recommend the source code version even if you do not exactly need it for your customers, because knowing exactly what is behind the API and being able to fully debug the application gives you an advantage over your competitors and solve your problems in a much more efficient way.
Upgrades ... be prepared for the future
I think the only remainig thing is to tell you how the upgrades to new versions work, if you have already made one, you already know. Still, keep reading, especially if you had to migrate from 1.9 to 2.x or 3.x, because I will explain why this is the past and that the future is bright.
You may be little confused by the picture, let's explain it, starting from the beginning. At first, there was the version 1.x and you used small upgrade packages to upgrade your project. The upgrade package
(orange arrow on the left)
is a simple zip file containing SQL database script
and new / updated files of the user interface
, also with all the new DLLs
. The upgrade procedure works the way that you follow the instructions and usually run the SQL script over your database and replace the files in your project. It is very simple and we leave it to you rather than to some automated process to be sure you will take care about your backup and you can see what is actually going on. The process of upgrade with package takes from few minutes to about half an hour tops, including the backup of your project, depending on the complexity and how you upgrade. If you made some changes to the files which are new, you must take care that you do the changes in those, there is no automation process which could handle those.
This was working well until version 2.0 came out. The change of architecture broke the compatibility between 1.x and 2.x version but it had to be done, so the standard upgrade process had to be replaced by something else. Unfortunately for some of you, only half of the work was done automatically, by the aplication Migration toolkit
which transformed the data to the new database (purple arrows on the right). The pain of the other half was that the developers had to convert parts of their code manually (the big red arrow) which is the thing no one wants to do, right?
When you are already at the version 2.0 and higher, on the V2 architecture, you can be happy, because it was carefully designed to be future-proof and since then, the compatibility stays with the solution. All the upgrades are done by the small upgrade packages
, even to major versions
, without any significant changes required to your code. You can expect the same for the next versions, we do not have any unwanted surprises for you so the upgrade process will stay smooth and fast for you.
Is this good or bad? Definitely GOOD for you!
Because the worst thing you can ever do to your product is to stick with bad version of it. Yes, we made a mistake in the past, but we have learned from it which brought you a product which you can choose just for its great architecture and features. That is what is valued.
How about source code updates?
Source code updates are little bit more complicated. Since every customer does the changes by himself, we are not able to provide you with the tool that could handle it. If you change something, you should keep track of that to be able to change it in the new version. You can keep a list of changes, mark them with comments or use some comparisson tool to compare your changes against the original version. If you want to compare your changes, I recommend you the great tool Beyond Compare
. Of course you need to recompile your solution and run the SQL upgrade to your database in that case.
Enough, let's have some rest
Thank you for staying with my maybe too long post, I will get back to you as soon as possible, because I already owe you the September summary. See you later ...