title: Placement of DTO / POCO in a three tier project
body: <p>I've been in the process of re-writing the back-end for a web site and have been moving it towards a three-tiered architecture.</p>
  
  <p>My intention is to structure it so:</p>
  
  <p><code>Web site &lt;--&gt; WCF Service (1) &lt;--&gt; Business Layer (2) &lt;--&gt; Data Layer (3)</code></p>
  
  <p>My issue is with the placement of the DTO's within this structure. I'll need to use DTO's to move data between the business layer and the WCF service and from the WCF service to the consuming web site. </p>
  
  <p>During my research on here I've read some excellent discussions though I've been left scratching my head a bit:</p>
  
  <ul>
  <li><p>Davide Piras makes some great points in <a href="https://stackoverflow.com/a/7474357/543538">this post</a> and if I were to follow this design then I'd declare interfaces for the POCOs in a separate project. These would then be implemented by tiers (1) and (2). Whilst I like the use of interfaces it does seem like I'd be making more work for myself by declaring POCOs in (1) and (2) and then copying their data back and forth using something like AutoMapper.</p></li>
  <li><p><a href="https://stackoverflow.com/a/7510526/543538">This post</a> uses a system where a business objects project is created which would be referenced by all tiers. This seems to be simplier than the other solution and seems to lead me to a solution that would be </p></li>
  </ul>
  
  <p><code> Web site &lt;--> WCF Service (1) &lt;--> Business Layer (2) &lt;--> Data Layer (3)</p>
  
  <pre><code>^               ^                       ^
  |               |                       |
  [ -- Business Objects Referenced here --]
  </code></pre>
  
  <p></code></p>
  
  <p>My question is this: is there a code smell from sharing the business objects across three layers of the solution or are the two methods I've listed above just two different ways of cracking the same nut?</p>