Doctrine 2.5 has embedded objects feature, but what I am looking is a collection of these objects like Java Persistence API has. Basically, an annotation #ElementCollection is what I am looking for doctrine.
Looks like Doctrine had such functionality developed in 2.2 version, but is it left over or what?
Doctrine 2.5 does not support multiple embedded objects yet.
But you have following alternative solutions :
Serialising a collection of embedded objects into a single column
Map them as entity and one-to-many relationship but use OO to enforce the embedded object 's characteristic.For example , to well encapsulate them such that its lifecycle and behaviour can only be managed by its parent.
Reference:
Domain-Driven Design in PHP - Persisting a Collection of Value Objects
Persisting Value Objects in Doctrine
Related
I have annotated a JPA entity both with #Entity and #Document (from Spring Data Elasticsearch) so I am basically indexing into Elasticsearch the same POJO as JPA.
Is this a good and recommended practice?
If not, what is the alternative? Having two distinct POJOs and mapping the JPA entity to the ES document using something like Dozer?
I think it depends on your use case and the complexity of your object model. For a simple object model, I think that's fine. For a more complex object model, there are a few things to think about:
Do you really want/need to index all of the properties on the entity?
Do you need to transform the object before indexing it? For example, flattening relationships.
Will the serialization to ES cause lazy relationships to be loaded when you don't want them to be loaded?
If not, what is the alternative? Having two distinct POJOs and mapping
the JPA entity to the ES document using something like Dozer?
It looks like Spring Data Elasticsearch is using Jackson for serialization. That's a pretty basic default configuration. If that doesn't work for you and you don't want to introduce a DTO type object, you can always implement your own mapper.
Breeze supports inheritance as of 1.3.2. The DocTest unit tests demonstrate TPH, TPT, and TPC inheritance, based on an Entity Framework server. I am trying to create a similar data service, with similar type inheritance, e.g BankAccount as a subtype of EntityBase, but using MongoDb in the server instead of EF. So I'm loosely following the Zza sample (except not using Angular.js).
The Zza sample does not use inheritance, and it uses a basic JSON format for its metadata. When I fetched the metadata from the DocTest
http://localhost:45678/breeze/inheritance/Metadata
it appears to be in a different format (JSDL?), so I'm stuck with trying to come up with an equivalent JSON format. Initially this looks like adding "abstract": "true" to my base type in the metadata and "baseType":"EntityBase" to derived types.
Is there any reason to think this won't work without EF? And any reason to prefer TPH (Table Per Hierarchy) over TPC (Table Per Class), for example?
The Breeze client doesn't care if the backend is EF or Mongo, and inheritance is supported for either. What is different between Mongo and EF is that with EF we are able to extract metadata about inheritance relationships from the EF model. This is not possible with Mongo because there is no real metadata about the model stored in the Mongo database. This means that with Mongo you have to create the metadata on the client via Breeze's metadata api. It is completely up to you as to whether and how to create an inheritance structure in the metadata that matches what will be returned from a Mongo query. Take a look at the http://www.breezejs.com/documentation/metadata-by-hand for more information.
In zend_db 1.x we used reference_map to implements constaints and relations in the data mapper classes. In zend_db 2.0 where should the reference map go?
There is no referencing possible in ZF 2.0
You can see from my previous question that in ZF 2 you'll be either using a full blown ORM like Doctrine 2 or Propel for these kind of purposes or to write your own SQL Queries. The Zend DB Component is seen as a lightweight abstraction to handle simple task related stuff.
Say I want to populate a JPA entity using values supplied by a user through a web application form (Tapestry for that matter).
What is the best way to obtain the "blank" instance of the JPA entity that is going to be bound to the form fields?
As of now I just use the new operator as follows in my Tapestry class:
childminderAccount = new ChildminderAccount();
Is this not a somewhat a crude way of doing it? Is there a better way?
Nope, that's the best way to do it. One of the advantages of JPA (over old EJB Persistence) is that it is a "lighter" framework. One of it's lightnesses is the fact that it now works woth POJOs (or Java Beans). I would recommend however to take a look at Java's new validation API which is very lightweight as well, and it can insure that a JPA Bean is correctly populated from your form (like no non-nullable fields set to null, empty id field etc):
http://www.hibernate.org/subprojects/validator.html
I found a great tutorial on how to use Model Binding and List, Editable Grid / List Binding in MVC2. It shows how to create objects containing lists of type List<T>. But when I use the ADO.NET entity data model I cannot make the this:
SomeEntityCollection[i]
And thereby I can not make what is done in the tutorial.
Is there a way to work around this? Maybe make the ADO.NET use lists instead, if that's possible?
The best way I have found to map from ADO.NET to models is to use AutoMapper. It's a very elegant way to formalize mapping between structures.
From their site:
AutoMapper uses a fluent configuration API to define an object-object mapping strategy. AutoMapper uses a convention-based matching algorithm to match up source to destination values. Currently, AutoMapper is geared towards model projection scenarios to flatten complex object models to DTOs and other simple objects, whose design is better suited for serialization, communication, messaging, or simply an anti-corruption layer between the domain and application layer.