New answers tagged

0

Putting business logic in a DBMS can afford some logical layering, but has significant practical and strategic drawbacks: Lock-in. Your code will be bound to that database and its available facilities, probably forever. Database migrations have historically proven extremely hard, and are thus very rare. Database lock-in has been an extensive and expensive ...


0

Though it does seem supperfluous it could lay in the ground works to make the move at a later time easier. You could however emulate the business logic by having thin wrappers where all the db interaction code will be. Then use this to construct your Data objects for use in the rest of the system. On the other side of the argument is YAGNI... unless it ...


0

IMO I would duplicate the code, make the necessary changes and then refactor whetever duplication remains. Sometimes, you have to make a mess before you can start cleaning up. But I would agree with Kilian Foth's comment. There is something much deeper here. The problem is that if this case happens, then DoSomething was not a good method int the first place....


2

If someone is going to change a method which is reused somewhere in your codebase, he should be responsible for making an impact analysis before. So a dev who starts to implement a change in DoSomething should check beforehand from where this method is called. So lets assume you already found out DoThisSomethingAndMore won't work any more correctly when ...



Top 50 recent answers are included