title: API architecture
body: <p>I am in the process of designing an API. I would like to know if what I have come up with is a good solution:</p>
  
  <p>I have a respository type of data layer that talks to a database by converting business classes into entities(generated from LLBL GEN, I didn't want to use the entities directly as my business objects because I wanted to keep them simple and allow me to swap out to Entity Framework or some other mapper is I needed to)</p>
  
  <p>I have a WCF service layer that I'm using as a type of facade. It calls the respository layer and converts the business objects to DTOs and passes them through the API service call via a message to the client. The client can be an ASPX website, Silverlight app, WPF app, or even a WP7 app. The problem I keep runnnig into is when I want to run business logic I have to send the DTO back to the WCF service and then back to the client. This doesn't seem "right" to me. I can't put business logic in the DTO because that defeats the purpose. But if I want business type code to run on the client I have a lot of duplication of code throughout my different clients. </p>
  
  <p>My business layer does not know of the data layer, my data layer knows of the business layer and my facade layer knows of the data layer and the business layer and the DTOs. Is this a bad design for an API? And can anyone offer me any suggestions? I have only learned of enterprise level apps through reading different articles online.</p>
  
  <p>Thanks!</p>