tag:blogger.com,1999:blog-3237724005744642470.post5716376406856310928..comments2020-05-08T12:31:27.297+01:00Roger Hugheshttp://www.blogger.com/profile/07042290171112551665[email protected]Blogger2125tag:blogger.com,1999:blog-3237724005744642470.post-89041046851539258452014-08-01T09:03:52.549+01:002014-08-01T09:03:52.549+01:00Hi Roger. Totally agree with you on this one.<br /><br />Any IT problem could in theory be implemented by using custom electronics, boolean gates. etc. This would create an ultra fast and efficient system, however would be incredibly difficult to make. This is why software was invented in the first place, so that lesser mortals like us programmers, can make amazing things. I&#39;ll say that again, the *only* reason software exists, is to make it *EASY* for humans! - a few lines of code, could be orchestrating millions of hardware logic gates to produce the solution required.<br /><br />I don&#39;t care what is, or isn&#39;t &#39;Best Practise&#39;. The ongoing pursuit to take a single class solution, which is easily understood by even a novice programmer, splitting it down into N tier, multiple classes, does not make it easier. A maintenance programmer now has to understand the interactions between those classes in order to make changes. Its more complex. Ultimately, it will end up a even worse mess of spaghetti code, should a maintenance programmer not fully understand the original design intent and start hacking in code where it shouldn&#39;t go.Anonymous[email protected]tag:blogger.com,1999:blog-3237724005744642470.post-62622312553898600942014-06-20T09:16:30.183+01:002014-06-20T09:16:30.183+01:00Hi!<br /><br />The problem I see, is that there is no good solution for all problems. There are only not-so-bad solutions, from which we can choose as a developers.<br /><br />For instance: using DAO and Service layer may seem as a overhead for simple &quot;find&quot;, but this overhead is often acknowledged to make methods coherent across different use-cases (the ones which actually need some action is Business Service Layer).<br /><br />I agree, choose right design for right solution, but also choose design which is more-or-less coherent across whole application - that way the codebase is also more understandable for new developers. So yes, UserService just delegates finding user by id, to DAO, but also contains other methods and logic is in one place.<br /><br />Cheers!knedlehttps://www.blogger.com/profile/06835847901885640064[email protected]