4 ms·

Can you provide a concrete examples?

• mistermann 14y ago
  Ok, here's one extremely simple example.... Say you have a screen where you have to show sales for an individual customer. One way of doing this is, within the screen that requires this data, querying sales by that customer using the dynamic sql feature provided by the ORM you are already using. One line of code, and it exists in the source code exactly where it is consumed at runtime. Another way of doing this is writing a stored procedure that returns the same data and accepts customer name as an argument. Now, this SP has to be exposed through <n> application layers before the UI can ultimately call it. So now, you have a very specific (and obscure) stored procedure, that has to be exposed in <n> layers of application tiers. Now imagine you need sales for an individual customer, but now only for products from a particular manufacturer, and imagine the two ways that could be implemented. Rinse and repeat for every other distinct data retrieval use case you have. This is just one type of an implementation style that can be made excessively complex. Now throw some new design patterns that you just read about into the mix. Now, on top of your <n> app tiers, you now get several additional wrapper classes on top of all this, so a simple select from your database ends up with a call stack 12 levels deep with 6 levels of indirection. And if you suggest perhaps there's an alternate way, you're an outcast. At the very least, one would hope you could have an open-minded discussion about the relative merits of the two approaches. But this is just my experience, YMMV.
  • slewis 14y ago
    That's a good example and it does suck. Sounds like enterprisey java-land that we HNers love to hate on so much.