0

I have a solution with an onion architecture using an asp.net MVC project. I also access Active Directory, and was wondering if one needs to loosely couple Active Directory access? Say I have :

  1. Entity Framework POCOs
  2. Repository
  3. Service
  4. MVC

The way I currently do it is by adding Active Directory operations classes directly into MVC's Model folder. Should I instead add this access to my repository? I don't think my company will change its directory service, but who knows ...

1

What you are asking is opinionated, therefore the answer is: it depends!

The main conception of the Onion Architecture is that dependencies point inward the circle but never out. You should choose responsibilities of your application layers. As you wrote:

The way I currently did it is add Active Directory operations classes directly into MVC's Model folder.

This sounds as it's currently an application layer responsibility, which of course may be good or bad, only you can decide.

But, I see three main ways to implement this:

  1. Application layer: in the UI layer as it currently is

  2. Service layer: access the AD from your service classes, in which way you can have a "shared" access of said functionality

  3. Repository layer: abstract away all the AD related queries/updates you need.

If your fear is that your company would change authenticating from AD to say TACACS, you can have implementations of IAuthenticationEngine in an assembly that is concerned about infrastructure level stuff.

To sum up all these: this is an infrastructure concern, therefore I would definitely just separate these responsibilities away into points 2 OR 3, maybe 2 AND 3. Again this all depends on your needs.


To answer your question in comment: I see you have fallen into the typical trap of following the examples presented about the Onion Arch. As you currently have the flow of your program, you are just creating levels of abstraction for no real benefit other than difficulty. I suggest you to read this answer I wrote on StackOverflow, about a similar question you are facing right now. In short it is about you might not really need to have the code flow all those layers. Just use vertical slices of the layers.

  • I see. I don't believe my company would change but since persistence is very often a requisite, I would imagine you have to be prepared for anything. The way I did it is Service calls Repo that accesses DB. So I guess AD access should indeed be in Repo? I actually was starting my internship and did alot of AD methods before starting software architecture which I had not heard of before. And now there are so many methods, refactoring this will take a long time! – Flexabust Bergson Sep 14 '17 at 20:01
  • 1
    Wow, if that's the case well I have lost a lotttt of time :( I did inspire myself from an onion architecture developed by quite a good developer, see code here : code.msdn.microsoft.com/Onion-Architecture-In-9c58c06d and he does it that way. I guess it still has the benefit of losening the coupling doesn't it? I have to admit that I have a very hard time understanding software architecture – Flexabust Bergson Sep 15 '17 at 12:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.