3 ms·

The counterexample to the this line of reasoning comes in the form of nightmarish home-grown frameworks that have emerged slowly from years of piecemeal additio

by macNchz 10y ago

The counterexample to the this line of reasoning comes in the form of nightmarish home-grown frameworks that have emerged slowly from years of piecemeal additions to that original small problem. These accidental frameworks often wind up replicating many features of prefab frameworks, without any of the tests, documentation or architectural forethought that would have come with a pre built one. I don't always see the need for a framework, but once you've gone through the process of learning the ins and outs of one, which does indeed take extra time the first time around, it's a familiar tool and can really speed things up when you re-use it in the future. Now if you try out a new framework on every new project, that's a different story...

gwbas1c 10y ago
I think the crux of the original point is: Don't use a framework when you need a library. For example, I ripped NHibernate out of a project because the SQLite database only had 6 tables. (Later reduced to 3 tables.) In this case: - The original author used NHibernate incorrectly, making the product 10,000x slower then it should be - There's a high learning curve to NHibernate that all newcomers to the project must go through - There's a risk of having to work around an NHibernate bug - We have to ship NHibernate and adapt to new versions or potential security holes - The lawyers have to approve of the NHibernate license - A small, infrequently updated xml file using built-in serializers is much easier to work with then SQLite + NHibernate. Sure, we probably have about 1000 lines of DAL code instead of 200 lines of hbm files; but it's DAL code that's bug-free and has no external dependency risk. Would I use NHibernate, or a different DAL framework, in a different context? Sure! If we had many more tables, and changed our schema frequently, it would be the correct thing to use. It's all about understanding when to use a framework versus a library.

by macNchz 10y ago

gwbas1c 10y ago

I think the crux of the original point is: Don't use a framework when you need a library. For example, I ripped NHibernate out of a project because the SQLite database only had 6 tables. (Later reduced to 3 tables.) In this case: - The original author used NHibernate incorrectly, making the product 10,000x slower then it should be - There's a high learning curve to NHibernate that all newcomers to the project must go through - There's a risk of having to work around an NHibernate bug - We have to ship NHibernate and adapt to new versions or potential security holes - The lawyers have to approve of the NHibernate license - A small, infrequently updated xml file using built-in serializers is much easier to work with then SQLite + NHibernate. Sure, we probably have about 1000 lines of DAL code instead of 200 lines of hbm files; but it's DAL code that's bug-free and has no external dependency risk. Would I use NHibernate, or a different DAL framework, in a different context? Sure! If we had many more tables, and changed our schema frequently, it would be the correct thing to use. It's all about understanding when to use a framework versus a library.