Note that there are some explanatory texts on larger screens.

plurals
  1. POKeeping everything loosely coupled and extendable: Too many layers, too small ROI?
    text
    copied!<p>I (now more than ever) see developers write huge amounts of layers such as:</p> <p><code></p> <pre><code>implementation PresentationLayer -&gt; interface IMyDTO -&gt; implementation MyDTO -&gt; interface IMyService -&gt; implementation MyService -&gt; interface IMyDomainRepository -&gt; implementation MyDomainRepository -&gt; interface IMyDomainObject -&gt; implementation MyDomainObject -&gt; interface IMyIndependentStorageLayer -&gt; implementation MyMSSQLStorageLayer </code></pre> <p></code></p> <p>Looking through C# blogs, this seems the best thing since sliced bread. Basically, everything is loosely coupled. Don't use a domain object directly. Run everything through a service layer. Access data through a repository. All layers are perfectly independent.</p> <p>Don't get me wrong, I like the idea, but isn't the trade-off in time huge, especially on a larger project? Is the ROI in maintenance really large enough to justify this?</p> <p>The explanations I read are kind of awkward, such as "this way I can attach a different database if I need to". Really? I don't think it's a common problem that somebody suddenly demands to switch from MSSQL to Oracle and now you sit there and wish you had a million layers that all don't know of each other.</p> <p>Is there a trend on going overboard with loose coupling, or am I just reading the wrong blogs? How do you feel about this, and have you had instances where you were really glad later that you did the extra work in the beginning?</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload