Curse of inheritance in mvcExpress

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.

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.

Conclusion:

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!

Thanks, man. Awesame job done.
I watch over you closely for last year. Now we are going to give this framework a try.

PS: don’t ever try to speak with 2 morons. Better del both comments.

As for inheritance hell. well why are you bothering about extending the framework when the inheritance became real challenge at earlier stages. I always wanted to use multiple iheritance to control behaviour of the object, but onl yone parent forces us to incapsulate all possible controllers into the object. So I have only one grief – you got the only iheritance slot existed for defining the MVC role of the object.
At this case parsley looks more suitable. Bit for sure, we are going to look into mvcexpress because of speed/

can you explain in more detail what you mean by “inheritance slot for defining MVC role” ? maybe with example, and why it’s important.
Maybe it is missing feature of mvcExpress, or maybe extension can be created for it.

For me dirty mediator is Mediator, that mediated by another Mediator(it is injected in another mediator, map and mediate are called for dirty), but dirty not registred in MVCExpress framework (no map or mediate for it), but important thins he can do – is send message. So, this is some hack, to not create some VC to mediated and send flash Events, that listens some Mediator, and just send directly MVC message from it. What you think about class, that some VC can be extended from, and be able just send MVC message?

Injecting proxies into mediators is a weak practice… but its not the problem if you use it for read only data time to time… having application logic in mediators instead of commands is very bed practice – application becomes much harder to maintain and scale.

I want to finish V2 and then think about training material again. In any case – if you have questions feel free to ask!