How to retrieve Domain Object from Repositories

Question

I have a little problem understanding repository-domain object relation. Here is some information I know about domain design(they may also be wrong or not accurate). And with these in mind, I can't find a way to obtain a domain object from the repository.

In DDD the domain should know and contain only whats needed for the business and everything else must be cleared out of the domain. That's fine. And also abstracting data access from any business is a good practice too. The application doesn't need to know where we store data or how we store data. We only ask the repository to give us a domain object and it gives us the object we want or the other way is valid too, we give the repository a domain object and it sends it to the storage.

Declaring public setters for domain objects is also a very bad approach in object oriented design since we won't be able to control who is accessing what and changing what. So it is a good practice to expose only whats needed for outside of the object.

So with these in my mind, I can't figure out a way to implement my repositories. I can use any ORM or pure sql in my code and retrieve data.

But I can't create domain objects from persistence objects;

1. Since they don't have public setters, I can't create and set the field values.
2. Declaring public constructors containing all of the fields doesn't seems right. I might have several models to fill in, this means I have to define several constructors with different sets of parameters.

Any help will be appreciated...

Beaker

Answer 1

There are options you have:

1. ORMs can work with private fields.

As I know, ORMs (e.g. Entity Framework, NHibernate) can set properties via non-public setters.

There is an example that proves it for Entity Framework - Entity Framework, Private Constructors and Private Setters.

If you use NHibernate your setters should be public/protected virtual/protected internal virtual or private backing field can be used. You can find more information in the Property Access strategies in NHibernate SO question.

2. Reflection can be used.

It can be used to get access to private fields/properties also. It is possible to set private property via reflection.

3. It is not a bad practice to have public constructor to construct your entity.

Declaring public constructors containing all of the fields doesn't seems right. I might have several models to fill in, this means I have to define several constructors with different sets of parameters.

Your Domain Entities need only one public constructor with full list of properties they have. It is enough to have only one constructor in spite of having several models to fill in. It is a responsibility of repository to invoke constructor and map model into its parameters correctly.

Edit:

4. Automapper can be used.

The following test shows that AutoMapper can map properties via private setters.

[TestClass]
public class AutomapperTest
{
    [TestMethod]
    public void Test()
    {
        // arrange
        Mapper.CreateMap<AModel, A>();
        var model = new AModel { Value = 100 };

        //act
        var entity = Mapper.Map<A>(model);

        // assert
        entity.Value.Should().Be(100);
        entity.Value.Should().Be(model.Value);
    }
}

public class AModel
{
    public int Value { get; set; }
}

public class A
{
    public int Value { get; private set; }
} 

Gastrotrich

Thanks for the tip. But I've read an article which mentions domain model and persistence models are two different sets, and I think that's right. On my current project, there is a very bad db-first design which is a complete disaster for domain logic. That's why I don't want to use my EF entities. So I need a seperate domain class set which express the desired domain in a better way. My question is; how can I get the data from EF entities to my domain objects which does not expose public properties? sapiensworks.com/blog/post/2012/04/20/… – Beaker

You repositories (specific data mappers) can be responsible for mapping EF Entities into Domain Entities. I am okay with having single public constructor that is used in order to build Domain Entity. One more tip - your mappers might be similar to Builder or Factory patterns. – Gastrotrich

If you're going to map manually then consider removing EF model completely as it's just slowing thing down. Your repositories can use plain DataReaders. – Phantasm

Thanks Ilya, I'll consider using AutoMapper. I didn't know it can map to private properties... – Beaker

@BartłomiejSzypelow, It was the solution I used in one of my projects. We simply used DataReaders, but it involved writing of annoying stored procedures. – Gastrotrich

@ayk, AutoMapper is a good choice. I didn't know either that it can map properties via private setters. – Gastrotrich

Answer 2

It's not true you can't create domain objects with ORM not having public setters. If you're using Entity Framework, it definitely can map private properties in model first approach and you only need public getters in code first approach. I don't know how about other ORM-s.

Aviatrix

Answer 3

I am trying to understand your query here. Some tips on how you can proceed. First of all the Domain should know the repository contracts and not the actual repository infrastructure. in other words, you may choose to have 3 class libs as follows

1. XYZDomain (will know XYZRepository and make call on the appropriate methods of this interface)
2. XYZRepository (contains Interface IXYZService interface)
3. XYZSQLRepository(actual implementation of XYZRepository interfaces).

Now it's up to you to choose where to inject XYZSQLRepository to the XYZDomain using Dependency injection.

You can also try using eventing model to register these repositories if you want.

Use a custom Service Locator to get the concrete objects

Less

Firstly, thank you for your comment. But here I am not interested in decoupling details of the components. I am just wandering how can I obtain an object which exposes no fields publicly and expect it to come loaded from repository.. – Beaker

I hope you agree the business logic Or your domain in other words should agnostic of the infrastructure. If i understand you correctly you are trying to create repository that can bounce back Domain Objects and not the other way around. My view is that the business does not needs to change in infra (e.g. ORM changed to something different). The duty of your repository is to set the Domain using the public methods of the Domain Class. So if you are looking for how to set value then it will be using domain methods. Hope you got why it is methods and not setters – Less