title: Servicestack - architecture & reusing POCOs for everything
body: <p>I refer to <a href="https://github.com/ServiceStack/ServiceStack/wiki/Advantages-of-message-based-web-services#code-first-pocos" rel="noreferrer">ServiceStack documentation</a> reg use of POCOs:</p>
  <blockquote>
  <p>Since it promotes clean, re-usable code, ServiceStack has always encouraged the use of <strong>code-first POCO's for just about everything.</strong></p>
  <p><strong>i.e. the same POCO can be used:</strong><br />
  In Request and Response DTO's (on client and server)<br />
  In JSON, JSV and CSV Text Serializers<br />
  As the data model in OrmLite, db4o and NHibernate<br />
  As the entities stored in Redis<br />
  As blobs stored in Caches and Sessions<br />
  Dropped and executed in MQ's services&quot;</p>
  </blockquote>
  <p>I love servicestack &amp; how easy it is to write web services with it. I am trying to understand how best to setup my project &amp; not run into any issues down the road.</p>
  <p>Specifically, I am battling with the architectural idea of returning a response object that is also a data model (as suggested by SS). The idea of seperation of concerns is too strongly ingrained within me. Won't one run into problems down the road if you use the same POCOs for everything. Is it not &quot;safer&quot; to e.g return eg view objects instead?</p>