> Nope. If it works and it's stupid, it's still stupid. Successful businesses with successful and profitable products say otherwise. The fact that stuff gets

> Nope. If it works and it's stupid, it's still stupid. Successful businesses with successful and profitable products say otherwise. The fact that stuff gets done means that it's not dumb, at a base level. You may not like it - and a lot of people don't because it removes the need for overengineered, oversmart and other "solutions" when sometimes the best solutions is literally the "stupid" solution. > Noone is looking down on ORMs because they work, people are looking down on them because they don't work well enough to justify their downsides in most use cases. A decade of experience in a few companies I've worked at and every company I interview with says otherwise. EF is top notch and removes a large swath of "boilerplate" code and works more than well enough. I've had much better experiences with something like EF than I have with stored procedures and triggers and other "better" solutions. > Now are some things that people call "anti-patterns" actually the right thing in certain circumstances? Absolutely. See? you even admit that "anti-patterns" are the right patterns "in certain circumstances". The only thing you disagree with is how common those circumstances are and for the vast majority of circumstances? ORMs are a lot better than "custom" layers underneath. Nothing worse than creating a custom way of doing something that's already done. Inserting your own bugs. etc. Smart programmers don't solve problems that are already solved. I wouldn't create a PDF parser from scratch (outside of learning excercises). I wouldn't create a Word Document parser. XML parser. etc... Why would I create a data layer management package when I have better things to do with my time that actually adds value to a company?