+972 52-548-6969
Value of a framework
One important criteria about frameworks is how it handle complexity. For instance, consider VB6. You really don't need to do anything with it to get usable COM objects with all the fancy interfaces that you can want, and writing office automation there was actually easy. But try to write mutli threaded app in VB6, and you're up against a wall.
I like MonoRail and I don't Like WebForms. It's probably easier to design pages using WebForms for most common scenarios. It's easy to write views in MonoRail in nearly any scenario. Both frameworks uses the same ASP.Net stack (ASP.Net != WebForms !!!), both allow me to write pages pretty easily. But WebForms hides the eventless nature of the web with quite a bit of complexity of its own. MonoRail does quite a bit to reduce the amount of stuff that I need to do manually, but it manage this complexity, it doesn't hide it. I can easily change the amount of stuff the framework does for me (from full blown parameters-to-database-objects to let-me-do-it-all-alone) on a case by case basis, with no consequences.
The way I see it, a good framework should manage complexity, a bad framework hide complexity. A framework that hide complexity will limit what I can do with it pretty quickly. The problem is that you don't feel the pain until you are commited and starting to do the complex stuff.
Comments
Comment preview