Does Morphia honor javax.persistence annotations? I have a scenario where I need to publish a light weight object model with minimal dependencies, and then have separate modules choose how it performs it's persistence using this common object model.
No it does not unfortunately. Most of those annotations wouldn't apply to morphia models anyway so it might be more confusing than it's worth.
Related
I want to avoid using proprietary Jackson annotations on my JPA entities, but need to serialize them. If I do, I will run into an exception because my a parent is referenced through the child causing a cycle.
Are there any alternatives to marking up my entities, could Jackson be configured to look at the JPA annotations and ignore ones with a mappedBy property? Or is there another way to achieve this?
I don't know any ways to directly ask Jackson to ignore the the recursive without annotations. But if you want to force him to ignore any fields with a special annotation you could write some custom serializer in addition of reflection to avoid them.
http://static.javadoc.io/com.fasterxml.jackson.core/jackson-databind/2.9.1/com/fasterxml/jackson/databind/JsonSerializer.html
Reading about using Java Generics in DAO layer, I have a doubt applying this in spring data repositories. I mean, with spring data repositories, you have something like this:
public interface OrderRepository extends CrudRepository<Order,OrderPK>{
}
But if I have other 10 entities, I have to create 10 interfaces like the one above to execute CRUD operations and so on and I think this is not very scalable. Java Generics and DAO is about creating one interface and one implementation and reuse this for entities but with Spring Data repositories I have to create one interface for each entity so ...
You didn't really state a question, so I just add
Is this really true? And if so, why?
and answer it:
Yes, this is (almost) correct. Almost, because you should not create one repository per entity, but one repository per Aggregate Root. See http://static.olivergierke.de/lectures/ddd-and-spring/
Spring Data Repositories offer various features for which Spring Data needs to know, what entity it is dealing with. For example query methods need to know the properties of the entity, in order to convert the method name to JPA based query. So you have to pass in the information to Spring Data at some point and you also have to pass in the information, which entities should be considered Aggregate Roots. The way you do that, is by specifying the interface.
Do you really need that? Well if all you want is generic Crud functionality, you can get that straight out of the box with JPA. But if you want query methods, Pagination, simple native queries and much more Spring Data is a nice way to avoid lots of boiler-plate code.
(Please keep in mind that I'm biased)
I'm using Salat library to serialize objects to be stored in MongoDb via Casbah. Sometimes I need to tune little bit how fields will be serialized, and Salat's Annotations is a pretty convenient way to do it.
BUT, Is there any way to describe serialization parameters(Key, Ignore etc) not directly in case-classes(models) via Annotations, but in some external point, to keep my models clear from Salat dependency(aka POJO/POCO)?
Yes, you can add custom serialization logic to your Salat context.
Example from Salat unit tests:
WibbleTransformer
Custom context with custom transformers added
I'm trying to implement fully valid persistence ignorance with little effort. I have many questions though:
The simplest option
It's really straightforward - is it okay to have Entities annotated with Spring Data annotations just like in SOA (but make them really do the logic)? What are the consequences other than having to use persistance annotation in the Entities, which doesn't really follow PI principle? I mean is it really the case with Spring Data - it provides nice repositories which do what repositories in DDD should do. The problem is with Entities themself then...
The harder option
In order to make an Entity unaware of where the data it operates on came from it is natural to inject that data as an interface through constructor. Another advantage is that we always could perform lazy loading - which we have by default in Neo4j graph database for instance. The drawback is that Aggregates (which compose of Entities) will be totally aware of all data even if they don't use them - possibly it could led to debugging difficulties as data is totally exposed (DAO's would be hierarchical just like Aggregates). This would also force us to use some adapters for the repositories as they doesn't store real Entities anymore... And any translation is ugly... Another thing is that we cannot instantiate an Entity without such DAO - though there could be in-memory implementations in domain... again, more layers. Some say that injecting DAOs does break PI too.
The hardest option
The Entity could be wrapped around a lazy-loader which decides where data should come from. It could be both in-memory and in-database, and it could handle any operations which need transactions and so on. Complex layer though, but might be generic to some extent perhaps...? Have a read about it here
Do you know any other solution? Or maybe I'm missing something in mentioned ones. Please share your thoughts!
I achieve persistence ignorance (almost) for free, as a side effect of proper domain modeling.
In particular:
if you correctly define each context's boundary, you will obtain small entities without any need for lazy loading (that, actually becomes an antipattern/code smell in a DDD project)
if you can't simply use SQL into your repository, map a set of DTO to your db schema, and use them into factories to initialize entity classes.
In DDD projects, persistence ignorance is relevant for the domain model itself, not for repositories, factories and other applicative code. Indeed you are very unlikely to change the ORM and/or the DB in the future.
The only (but very strong) rational behind persistence ignorance of the domain model is separation of concerns: in the domain model you should express business invariants only! Persistence is an infrastructural concern!
For example without persistence ignorance (and with lazy loading) the domain model should handle possible exceptions from the db, it's complexity grows and business rules are buried under technological details.
Personally I find it near impossible to achieve a clean domain model when trying to use the same entities as the ORM.
My solution is to model my domain entities as I see fit and ensure that any ORM entities don't leak outside of the repositories. This means that my repositories accept and return domain entities.
This means you lose "most of your ORM goodness" and end up "using your ORM for simple CRUD operations".
Both of these trade-offs are fine for me, I would rather have a clean domain model that I can use, rather than one polluted with artefacts from my DB or ORM. It also cuts down the amount of time I spend "wrestling with my ORM" to zero.
As a side-note, I find document databases a much better fit for DDD.
Once you will provide persistence mapping in you domain model:
your code depends on framework. If you decided to change this framework, you want to change persistence layer and model layer source code - more work, more changes, more merging of code etc.
your domain model jar file depends on spring/nhibernate jars etc.
your classes become larger and larger how business code and persistence related code grows
I've to admit that I dont understand harder and hardest option.
We used separated interfaces and implementations for domain entities. Provide separated mapping files using Hibernate along with repositories.
Entities are created using factory (or repository later), identifier is generated within persistence layer, entity does not need it until it's being persisted.
Lazy loading is provided by special implementation of List once:
mapping of an entity contains it
entity/aggregate is fetched from persistence layer
The only issue is related to transaction as when you use lazy-loaded collection out of transaction scope, it fails.
I would follow the simplest option unless I ran into a stone wall. There are also pitfalls such as this when you adopt pi principle.
Somtimes some compromises are acceptable.
public class Order {
private String status;//my orm does not support enum
public Status status() {
return Status.of(this.status);
}
public is(Status status) {
return status() == status;//use status() instead of getStatus() in domain model
}
}
I have set up my project to work with Entity Framework. It is a database first approach.
For the IoC, I am using Castle Windsor and the project is set up to inject all the dependencies.
My question is, is there a need to set up Castle to do the same for my EF entity? How can I do that?
There are a number of ways to use Entity Framework with Castle. I would suggest that you adopt both the Unit of Work and Repository patterns. The DbContext provides most of the functionality for a unit of work, and DbSet similarly provides most of what is needed for a repository.
The main issue you will run into is that EF doesn't understand dependency injection for model objects. EF always uses the empty constructor when it allocates a model object, and this means we don't get the opportunity to do dependency injection into model objects. We have gotten around this by using the object materialization hook on the DbContext:
((IObjectContextAdapter)this).ObjectContext.ObjectMaterialized += EFObjectLoadInitializer;
The EFObjectLoadInitializer then injects the Kernel into the model object (all our model objects must support the IInjectKernel interface). Upon injection, the Kernel is then used to resolve any other dependencies. Its not very clean, but it works well and allows us to leverage off of the rest of the infrastructure that we have set up with Windsor.