solution architecture for an OData / Web API based .Net project

Question

so far in my office i have developed a number of small and medium sized .Net web based applications where i used to architect them something like this -

• Web layer (.Net Web APIs)
• Controllers, filters
• Services (contains business logic)
• IServices
• Repository (gets data from database using entity framework / ADO.Net)
• IRepository
• ViewModel
• Model

I used to have different projects for each of those listed above in my solution.

But now we are moving towards OData Web APIs and trying to get away with entity framework. So i am a bit confused about how my solution architecture should look like.

Question 1 - Where should my DBContext file be located?

Question 2 - How am i going to query using OData from Controller -> Service -> Repository

Question 3 - Can i still follow the architectural model given above and have OData instead of entity framework getting data from database?

Question 4 - I will still need a separate business logic layer (Service layer) between data source and controllers so i can keep my controllers as thin as possible

Please excuse if i am asking any wrong/silly question since this is my first effort trying to figure out how i can use OData to perform my tasks.

Answer 1

Following are the details of what we do in our project, if that can help you to an extent. We have Web API services, which have API controllers, which are used for Json serialize the end result. Following are the important layers and their respective roles:

1. Web API Controller

   • Receives the Rest request, Serialize / De-Serialize from / To C# objects

2. BL (Business Layer)

   • Business processing and External Service Integration (like Web services)

3. Helper Layer

   • In memory processing to convert simple Data entities / Poco's to complex UI / Return entities, which are finally converted to Json. This layer has lot of Linq to objects code to do the task well. It has fair amount of logic.
4. Repository Layer
   • Fetching the simple data entities, mostly as IEnumerable<T>, using our custom Micro ORM. Sometimes for specific cases we even fetch DataTable / Dataset directly and use them for further processing
5. ADO Helper (Custom Micro-ORM)
   • Use Reflection to fill a POCO at runtime, using DataReader or DataAdapter, this part can be replaced with any other dtaa fetch mechanism

Common Entities: (They can be accessed across layers defined above, though we restrict to ensure consistency)

Data - Simple POCO classes, which fills db data

UI - Final result entity

Input - For input from REST call

Constants - For hard coding and constant values across the project

All the C# layers below Web API can be created as dll, since the relation is unidirectional, from BL - Helper - Repository - ADO Helper. Any additional layer for a specific purpose can always be inserted or adjusted. It is important to separate the specific role of each entity.