ORM's have a big learning curve, especially troubleshooting, and tie your stack to an ORM brand. But the worth of ORM's are probably another topic. I'd like to

ORM's have a big learning curve, especially troubleshooting, and tie your stack to an ORM brand. But the worth of ORM's are probably another topic. I'd like to see a data-dictionary-driven approach where most of field info comes from a data dictionary, and only deviations need to be defined locally. (Or perhaps create and mark dummy columns in the data dictionary that are slated to be used for local customization.) I suppose one could push a button and have static classes or definitions generated for the source code from the data-dictionary, and thus still have a statically typed system. It's still duplication of field attribute info, but at least it's systematic duplication. I used to use systems/tools that integrated the database, business logic, and UI; and they reduced the amount of typing and code rework by a large amount. The multi-layered approach may give us cross-vendor flexibility, but at the cost of more code diddling to wire up the interfaces between all the layers. Layer independence seems to increase duplication of field-related info. Back then I could spend more time on requirements and analysis and less on code wiring and re-wiring. Now we waste too much time dealing with low-level repetitious grunt work.