release candidate for mvcExpress version 2 released!
I want to use this opportunity to talk about one thing that I am not happy regarding mvcExpress framework, I call it – curse of inheritance!
It is very hard to write this post, as it’s hard to criticize your own creation, but I think it is fair to share both good’s and bad’s to let you know there you are getting yourself into.
In short – extensibility mvcExpress currently is implemented by extending base classes. If you want to add a new feature to framework you will need to extend base classes, this leads to trees of inheritance. Inheritance have some negative effects: you will have some inconveniences, code duplication and in general writing custom mvcExpress extensions is possible, but not as easy as I would like it to be.
If you just want to use already written extensions – your are in luck! It is very easy to switch extensions(in most cases – just changing class you are extending), and if something goes wrong – framework has some dedicated code to figure out what went wrong. (For instance it will tell you if you are using class that is not supported by current module.)
I have no doubt that composition would support extension creation better, but I want to give my reasoning why in my opinion inheritance might actually work for mvcExpress. (…and I don’t want to follow path some other flash mvc framework, as I don’t like there it ended)
Seeing problems with inheritance in action, I had to remind myself of my vision for mvcExpress framework. Then I started it over 1 year ago I had 3 things in mind: speed, simplicity, and security. (Extendability was not there..) mvcExpress v1 looked very good, fast, minimalistic and just working for what it was created for. But then I started extending it I saw the problems – it was very hard to extend it. (without hacking it).
I decided to fix it in version 2, but very quickly discovered that I have to change essential things that made it so quick and easy. I decided not to do it, I decided to keep the speed and ease of use, and make some sacrifices that will result in writing extensions only possible, not necessarily easy thing to do, but, also at same time – keep it easy to use.
Here is example of inheritance tree for two available extensions :
It looks complicated but it really isn’t. Usually you start mvc application by extending ModuleCore. Then you use Mediator, Proxy, Command classes to construct your application. Lets say you decide to add modular programming features – you just extend ModuleScoped instead of ModuleCore, and you done! You can start using MediatorScoped, ProxyScoped, CommandScoped in places there you need those features. (you don’t need to change your old code that will not use scoping features, they will work fine). This gives possibility to add/remove features just by changing class you are extending, and keep your code base as light as possible.
Sadly this will also lead to same confusion regarding what classes you can use, but framework will help you there! If you by mistake use class that is not supported by current module, MediatorLive for example, framework will throw an error. The only thing you need to do to fix it – is change class you are extending your module from to ModuleScopedLive. This will give you freedom to use: Mediator, MediatorScoped, MediatorScopedLive, and MediatorLive depending on features you need.
It is also very easy to remove extension – just change class you are extending, fix errors that will pop up because of missing features, and you done.
If you want to create fast and reliable applications quickly by using already created extensions – mvcExpress is the best fit for you!
If you want to have ability to write extensions, mvcExpress might be not the best framework for you. (unless you don’t afraid to get your hands dirty.)
Thanks for your time.
Feel free to comments if you find an error , and in general, let me know what you think about mvcExpress extensions!