| Re: Maybe it is the convention over configuration mindset which results in lots of magic Yes, the "magic" is a double-edged sword. I find a similar problem with Dot-Net MVC: when the "helpers" work as intended, they are great. But when they don't, troubleshooting takes way too long. (MS-MVC is more or less a clone of R-on-R.) Its auto-matching of URL's to controllers & methods etc. (routing) is an example of this. A bunch of IF or CASE statements to do the same thing would probably be much quicker to debug, even if it's more typing up front. (Or even put the mappings into data tables for bigger apps.) One can scaffold (auto-generate) IF/CASE statements for such if needed to reduce the original build grunt-work. All these "magic helpers" are over-complicated and opaque. Yes, I know that once one gets used them they know how to cajole them, but the learning curve is unacceptable for things that should be relatively simple. The helpers are more trouble than they are worth because they try to fit too many application types and styles, and rely on reflection, which makes following the actual helper code a pasta factory visit. Must it be that way? I want clear and logical processing, not a bunch of organic dark-grey boxes. Maybe I'm old fashioned and relying on a bunch of dark-grey boxes glued together is the proper "new way"? #Idontgeddit Maybe it's better for big projects or large pool of devs where you hire plug-and-play specialists who know a specific technical area well such as routing or views. But in shops with smaller staff or that divide tasks by project or entity instead of tech specialties, this doesn't make sense. But orgs feel compelled to do it that way because "everybody else is": MVC-Lemmings. |