DDD Entity and ValueType with ORMLite

I just finish a course on pluralsight about Anemic Domain…
They talk about implementing more Type in your Entity.

I was wondering if it could be possible to save Private Property in the database so we could escape from one mapping extension. (DTO → MapToEntity → MapToDB)

Your advice are welcome, for an another solution. I could leave EmailAdress has a blob but it make reporting more difficult with other tools that don’t use ORMLite.

ex:

public class Person
{
    private string email;
    private bool isVerified;

    public string FirstName { get; set; }
    public string LastName { get; set; }
    [Ignore]
    public EmailAdress Email { get; set; }

    [UseInDB]
    private string Email { get => Email.Email; set => Email.Email = value; }
    [UseInDB]
    private bool IsVerified { get => Email.IsVerified; set => Email.IsVerified = value; }
}
public class EmailAdress
{
    public string Email { get; set; }
    public bool IsVerified { get; set; }
}

OrmLite is a code-first POCO ORM that maps 1:1 with RDBMS tables by design, I’d recommend against stuffing business logic in your POCO data models and try to coerce its public API in a different shape which is the approach NHibernate took which I’m definitely not a fan of which has since seen its market share and interest in it erode IMO because devs prefer simpler, cleaner + more intuitive ORMs.

Like all ServiceStack code-first POCO libraries OrmLite only recognizes public properties which I’ve no interest in changing with added unnecessary complexity for less intuitive behavior that runs contra to our anti complexity ethos.

I see no benefit to all the boilerplate you want to introduce which makes it harder to decipher the RDBS table layout from the code-first POCOs as compared to the natural layout:

public class Person
{
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public string Email { get; set; }
    public bool EmailVerified { get; set; }
}

My recommendation if you want to turn your Data Model into an Object model of a different shape is to not try conflate different concerns into the same model but to instead map it your object model that you have complete control over using something like AutoMapper or ServiceStack’s built-in auto mapping.

1 Like

Totally understand your point. Trying to make one part easier always bring complexity in other part. Thanks!