Onion Architecture, Project Architecting and Authentication

Question

I am learning ASP.NET MVC & Web API and trying to implement Onion Architecture with Repository Pattern for one of my Test projects as part of my learning.

I have developed single MVC Projects before, but not using layered and onion.

My idea is to give data to different clients (Web- MVC 5, Xamarin - Android) using a single Web API.

Here is the pattern/structure I am trying to follow:

1. Core Project

   • Entities
   • DTO's
   • RepositoryInterface(GenericRepository + Individual InterfaceRepository)

2. Infrastrcuture Project

   • Repositories (Implementing RepositoryInterfaces)
   • Migrations (Code First Workflow EF 6)
   • Mappings (using AutoMapper)
   • DbContext.cs

3. Test Project (NUnit)

4. WebApi 2 Project

   • Controllers with UnityDI
   • Token Based Authentication(?)

5. MVC 5 Project

   • Controllers to give out Views
   • User Authentication (?)

6. Xamarin Project

My questions are as follows -

1) Am I going in the right direction?

2) Is it Okay not to use UnitOfWork while using Repository Pattern?

3) I am really confused about Authentication. How should I authenticate my users and web api? Forms Authentication for users in my app? and token based for web api?

Any suggestion/links/advice are welcomed.

Answer 1

1) Am I going in the right direction?

This is a much too broad question if you want it answered with any amount of detail. We don't know exactly what your current experience is and whether there are things worth learning here.

The list you've made doesn't look wrong at first glance, but there are many ways in which you could do things wrong.
I've seen countless developers follow a certain structure without actually understanding its purpose (e.g. layer separation and SRP), and ending up heavily leaking their abstractions across layers anyway. The same could be happening here and I wouldn't have any way of knowing; so I'm apprehensive of telling you it's definitely good.

2) Is it Okay not to use UnitOfWork while using Repository Pattern?

In short: I've created repositories without units of work before, but once the code gets to any level beyond trivially simple CRUD operations, you will regret not having a UoW implemented. I would suggest implementing a UoW unless you know for a fact that your application will never handle any complex logic or transactions.

The repository pattern has one big drawback. I'm omitting architect-level concerns and I'm only addressing issues on the level you seem to be at.

The big drawback to repositories is that they have their own datacontext. This isn't an issue when your operations are always focused on one particular entity (or domain module), but the problem becomes more relevant once you start working with multiple entity types all at once (e.g. a complex report, or an import method which creates many types of entities).

First of all, where to put the code which retrieves all Foo objects and their related Bar objects? FooRepository? BarRepository? You will find a lot of disagreement here. Whichever location you choose, some developers will always expect it to be in the other location, or argue that it should be put in a third location altogether.

Secondly, repositories (without a unit of work) make you lose transactional integrity across several types. Let's say you have an import which is supposed to create 3 objects (a Foo, a Bar, and a Baz. However, should any of these actions fail, you want to ensure that none of the items get saved.

Without a unit of work, your FooRepository will have a different datacontext from your BarRepository, which leads to an inability to ensure that both/none of the items are saved to the database.

A unit of work, however, ensures that all your repositories (in the same uow object) share the same datacontext, and therefore you can retain transational integrity.

There are other workarounds to implement transactional integrity, but they are often dirty and notably inferior to the UoW implementation.

3) I am really confused about Authentication. How should I authenticate my users and web api? Forms Authentication for users in my app? and token based for web api?

This very much depends on what you're trying to accomplish. Who will be your end users? Random people? A certain company's employees? Is there a need for users to authenticate on the app and not just make the app freely accessible but lock all the information behind the same API? Do you require offline authentication and/or access to resources?

There is no one answer here. This needs a lot more explanation from your side, and it should be a separate question.