One of the core concepts of well architected code is being decoupled, but like so many of the good things in life if you do it to much it becomes bad for you.
Recently I worked on a piece if legacy code that from the UI to the Dal it passed an object though 7 classes and was converted from one object to the next 5 times. Their wasn’t any real difference from one object to the next. In some cases it was pulled from the data object and each item was passed as a parameter into a method where it was then put into a new object. The result was next to imposable to debug, even harder to read, and in a lot of places just plain sloppy.
In an earlier post N-Tier Design Revisit part 2 – Data Entities I talked about how data entities, poco, or dto (they are all basically the same thing more or less) work, they go from the UI though the Biz and to the Dal and back again. This creates a message that is passed, your code is still decoupled because the Data Entity basally contains no logic, it’s just holding data.
Wring an application is kind of like growing a garden, if you take care of it and maintain it, it stays nice and easy to maintain. If you neglect it it becomes difficult to maintain and will over time die. Decoupling is one of the things you do to make it easy to maintain your application, kind of like watering it, and just like watering it if you do it to much you’ll kill it.
No comments:
Post a Comment