Common Repository design

Question

What I have:

I am developing an Active Directory layer which will be used by a huge application with several modules having several solutions and projects...

I am fairly new to developing large scale solutions.

Because the current requirements are mostly to deal with User and Group objects in AD, my current solution looks like this,

• Extensions
  • UserPrincipalExtension (inherting from System.DirectoryServices.AccountManagement.UserPrincipal to add custom attributes and override FindByIdentity methods)
  • GroupPrincipalExtension (same as above but with GroupPrincipal...)
• Models (models have override methods, e.g. toString, constructors etc.)
  • ADUser
  • ADGroup
  • User
  • SomeUserObject
  • and so on...
• Repositories
  • ADUserRepo (CRUD for user, + isUserInGroup sort of methods)
  • ADGroupRepo (CRUD for group, + GetUsersInGroup sort of methods)
• General
  • Utilies (Get Context, etc..)

What I want OR confusion is at:

Because some methods are sort of common between User and Group Repositories, Would it be any beneficial to move all methods out of UserRepo and GroupRepo into a single DirectoryRepo class and delete these repositories ?

At the moment this is creating confusion for me who is developing this, but it may confuse or either FORCE a consumer of this code to add duplicate methods.

How can I overcome this problem?

---

I named these repositories but these are just static methods accessing AD, sorry if that created any confusion.

Here are few of my previous questions on SO, if you want to look at some of the related code

https://stackoverflow.com/questions/32689228/how-to-extract-a-method-which-is-using-using-keyword-and-is-disposable

https://stackoverflow.com/questions/32649304/repository-class

Answer 1

The key to answering that question is the use of the repositories. Are there cases where only the User or only the Group repository would be used? Are you more likely to in most situations access both the User and Groups at the same time? Once you can answer those questions you will be able to determine which is "Right" for application design.

In one application I was working on the repositories were very fragmented (1 per database table) and using them was very cumbersome. After some refactoring we were at less repositories but with more logical access patterns. IE: A user always needed what groups they were a part of and groups were never accessed except when accessing users so we combined the 2 together as they logically went together.

Since this is a new application I would look at keeping them seperate since it will be easier to combine them (IMO) than break them appart later. If you find after some development that having them seperate causes you to always instantiate both repositories, I would combine them at that point. No point instantiating 2 objects in 90% of your code just to instantiate 1 object in 10%.