Menu
As I'm working through my first large project with an ORM, I've started to realize that the ORM will be a big impediment to creating domain objects that are expressive and that convey intent.
That is, I understand that we don't want domain objects to be merely bags of publicly-accessible getters and setters. In addition, I'm beginning to realize that simply having IList<T> all over the place doesn't convey intent and could invite abuse by developers using these objects. For example, maybe it's better to have ReadOnlyCollection<T> exposed. (I'm using .NET and Entity Framework, by the way.) And instead of an IList<MyDomainObject>, I've found myself wanting to expose a list of objects that are derived from MyDomainObject. (None of these things are easy to do in EF. Maybe I need to use NHibernate or ADO.Net.)
My questions are: Am I going too far in trying to craft domain objects in this way? Should these concerns just be part of some other application component? Or should I have a "real" domain object (that has the expressive stuff) and a "dumb" POCO object that is hydrated by the ORM?
(Edits: The system ate a bunch of my angle brackets.)
830
Domain objects are the basic building blocks of an application. They are the objects that represent the data in the application. Domain objects are the objects that the user interacts with. They are the objects that the user manipulates.
Domain-Driven Design(DDD) is a collection of principles and patterns that help developers craft elegant object systems. Properly applied it can lead to software abstractions called domain models. These models encapsulate complex business logic, closing the gap between business reality and code.
A domain class represents a table column and it allows you to handle the column value as a Java object. In the Doma framework, a domain means all the values which a data type may contain. In short, a domain class is a user defined class that can be map to a column. The use of the domain classes is optional.
The domain object model is based on the Decision Optimization Center Application Data Model. It provides a simple way to map tables to Java classes, columns to attributes, and foreign keys to bidirectional references.
My view is that you let the EF do it's thing and create the freebie POCOs. You could also call them DTOs - their role is to be the bridge from memory to persistence and back. As far as your "domain" goes, I've never bought into the idea that your DB schema reflects a coherent domain model. As a result, I've always created a Domain layer on top of the Persistence (or repository) layer which represents the business domain, keeping the sausage factory that is Persistence out of the mix. This Domain layer can mash up your DTOs as required to make a developer-facing model that makes sense. Use a factory pattern to create Domain objects from the DTOs and vice versa - keep the DTOs out of the client code such that you can isolate schema changes from consumers.
It's more work, more mapping code etc but it's worth it - EF already cuts your code down, and I would argue you should in fact be taking time to code the domain logic and representation, it's what makes you better than a code generation tool :)
Good luck.
148
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
