1

When implementing the repository it's fairly easy for a stand alone class. Unfortunately, we are unable to use an ORM to manage our data access, so I'm trying to recreate some of the functionality manually (uggh).

For example, If I have a class User the implements a generic IRepository. Additionally, I may have a class called Task that also implements IRepository. If there is a One-to-Many relationship from User to Task I would plan to have some code like this:

Public class User : IRepository<T> where T : IEntity
{
    public string Name{get;set;}

    public list<Task> ....(This is where I start getting fuzzy)
}

I would like to be able to chain my calls for example:

User.Tasks; 

Would return a list of all of that users task. How would the data access for task should look to handle this, Also, how should the Task be defined in the User class. And lastly, what about eager/lazy loading the Task on a user? How can this be accomplished?

  • Your code is invalid, I think you mean public class User : IRepository<User> {..} – Joppe Jan 15 '16 at 1:46
1

Don't implement a repository interface on the entity itself, create a separate (service class) for it.

Given your example I would consider not doing a Task list on the user at all but just create a TaskRepository with a ListTasksByUser query.

If you need no direct access to tasks (independent of user), you could consider just storing the tasks alongside the other user data. A document database would work well there. With a relational DB you could hide the join inside the repository.

If you plan to have both a UserRepository and a TaskRepository I would consider just associating by ID and leave it there.

To attach references to the real object, eagerly or lazily, you could come up with a bunch of solutions, one may require more instrumentation on your entity then others.

You could map your entities to DTOs which contain ID foreign keys, when loading it will eagerly load the foreign entity and assign it. When done lazily you could use a proxy around the entity property and load on accessing the proxied property.

Another option would be to create a small Reference object to use for each relationship containing a Lazy<T> and the ID. You would need to provide delegates for the Lazy values after loading data.

IMHO it's more trouble then it's worth, lazy loading is overrated. Either you want something eagerly or not at all. A code path touching a lot of lazy properties can give a lot of performance issues (select+1).

  • Thanks for the comment, a lot of good thought provoking ideas. I'd love to hear some others chime in. – TreK Jan 15 '16 at 4:02

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.