I am performing a code review (VS2008/.NET 3.5). The development team has created several data access components in a DAC assembly.
I encountered a business proces assembly where every DAC is wrapped with a business component with no additional value or code.
Is this a right premature architectual step ? Just to be prepared for something going to happen like: caching or validation or transactions? All these last mentioned topics are not the case right now but could happen in the future.
I made a comment in the review that introducing this kind of architectual preparations is bloating the code-base. So try to introduce it only when it is really needed.
What are your experiences about this issue?
My vote is to always have business objects, and always write your applications in terms of them. This makes the application layer data access agnostic, and improves your flexibility overall. It does take a little more up-front work, but the dividends for any long-living application are more than worth it.