4

I currently am setup up a Visual Studio solution using the onion architecture. I have a pretty good understanding on how to structure the solution but I am running into a bit of a pickle. My solution is consuming multiple APIs. These API's are consumed using WCF, Soap Web services, and RESTSharp for REST services. I am not sure how to structure this.

The biggest confusion is around REST services since this not only uses RESTSharp but also some POCO classes that are used for serialization. I also have:

ApiResult<T> where T is any of the POCO classes.

My first thought was to create Infrastructure.RestSharp where I would implement my interfaces that all have return ApiResult but the questions is where do I put the these POCO classes and the ApiResult? They would have to go in the Core somewhere since the interfaces are using them, but where would be a good place to put them?

What about the WCF and soap services? Would I create a Infrastructure.WebServices?

Thomas
  • 5,888
  • 7
  • 44
  • 83
  • if i understand well, your solution expose an API via WCF/Soap/Rest Services ? – Cybermaxs Sep 19 '12 at 19:21
  • No, I consume multiple APIs. Some are WCF, some legacy SOAP and some are REST services. I am not sure where these fit in an onion architecture. – Thomas Sep 19 '12 at 22:43

1 Answers1

5

Maybe this will help. Here is a diagram I use for setting up my Visual Studio projects using Onion Architecture. The arrows show which projects have references to others. Blue boxes are projects that I create. The orange items are 3rd Party projects or .NET APIs.

  • The UnitTests, Web (UI), and Dependency Injection and Data Access Layer projects all reside on the outside layer of the onion.
  • All references point inward towards the Core (Except the outside layers, which can point sideways).
  • All APIs are accessed through outside layer projects.

Onion Architecture Diagram

Community
  • 1
  • 1
Dragn1821
  • 807
  • 2
  • 8
  • 19
  • 1
    Out of curiosity, let's assume you consume 5 separate API's. Two are REST based and you use something like RESTSharp, two are WCF and one is regular SOAP using asmx. Would you create one project per API (5 total) or would you create one project per technology (3 total, one for REST, WCF, and SOAP)? Or would you just create one API project and dump them all in there? Keep in mind that the number of API's consumed will grow? – Thomas Oct 03 '12 at 19:45
  • 1
    I would probably keep all the APIs in the same project, which would probably be the UI. I would try to keep the business code separated in a different project. The idea is to keep it separate so those pieces can be reused. You could write a desktop app, web app, or something else that all use the same business code DLL and not have to rewrite that part of your app. An update could be as simple as replacing the DLL in those apps. – Dragn1821 Dec 13 '12 at 13:04