expigo / winter Goto Github PK

Basic implementation should make it possible to provide custom name for the column that is shown in the DB

I guess i should go more for inheritance at the end of the day, more Spring-ish approach with ctors like JsonClassPathContainer(String configclasspath) with Container as a superclass. This will allow 'factory method' based Loader dependency resolution (is Loader even necessary at this point?). But it is still up to discussion (with myself).

The Entity class should be composed of all elements that are a part od DB table metadata, like Primary Key, Column and more to be thinked of later. Later on it will be a starting point in addressing the problem of Object-Relational Impedance Mismatch.

Too much code duplication in this one.

At this point only objects with no-arg ctors can be stored. Adding mentioned possibility looks like a quite of a challenge, but man, we're going for full-blown di container, aren't we?

It seems that introducing another layer of abstraction is the best choice (Item 73)

If a class with the annotation will be found within the application's packages, the root directory for component/bean scanning will be provided along. This dir will then be used by Loader to create the object graph of dependencies.

...and measure the performance improvements.

There must another acceptable way...

For now, neither di container nor orm framework can handle the situation, when one object is in composition relation with another. DI container is not able to resolve the dependency of an object that contains another field annotated with @Inject annotation (can go only one level deep).
On the other hand, ORM can only store object created of primitive types.

I belive that solutions to both of the problems will require the use of recursion of some kind.