On 8/1/11 22:20 , Stanislav Muhametsin wrote:
As for DCI, well, I have quite different approach than the one I've seen
in qi4j-samples. I'll link to it once my MSc thesis is complete. :)
Would be interesting to see! Let us know when it is available.
I've never used visualizer for model, although the idea is nifty. But I
think this is most important reason for me to use Qi4j - the idea of
mixins, concerns, side effects, and constraints. Basically, mostly very
well implemented code generation. For that, Qi4j is pretty much best
thing out there that I know.
That's my view as well. Just not sure whether I was alone in that view
or not :-)
For me, this is maybe where Qi4j went a little wrong. I admit that the
project I am currently using Qi4j in is very different from most
projects out there. The Qi4j (and pretty much 99% of other frameworks
out there) represents a "application-owned-repository" -vision, where
the application which uses this framework is the only one which can
access repository. However, my project has it opposite: "repository owns
application", ie there is a single repository, and multiple applications
(simultaneously) access it: read and write and create. Therefore one
single Qi4j app can not decide the format how to store entities, the
identity of entities comes from repository (and not application), etc
etc. This therefore renders the Qi4j's concepts of Entities and
UnitOfWork useless for me.
For format, there is nothing to stop from having an EntityStore that
uses entirely custom SQL, for example, for each entity. That would be
perfectly allowed, and endorsed.
Identity is trickier, but can be similar. There is a version of entity
creation that does not take an identity, and a IdentityGenerator can be
plugged in which simply returns "DUMMY", or something like that. This
can then be used by the EntityStore to create the real id's later on. I
think. Has to be tried.
I admit that the Qi4j currently has huuuge learning curve. Partly
because the tutorials are either impartial, or missing completely, or
outdated. And partly because the problem that Qi4j solves is inherently
complex. I haven't seen v2.0 branch yet, but I think currently the Qi4j
has a few unnecessarily complex things (in runtime projects), but
otherwise is as simple as it can be.
Qi4j v2.0 should be significantly simpler (no more *Composite interface
to bother with if you don't want to), and also more efficient (I've
reduced the memory footprint significantly, which Falko should like).
With something like templates for assembly, and the ClassScanner for
finding classes, that might be enough as a start.
This is once again a great idea for MOST applications, but for those
"special" ones the devs still need to throw all that away, and build it
from scratch. But I agree that providing ready-made templates is good
for learning curve. I think that most of those 'templates' could be
ripped off directly from classes in test-support.
For real apps, I'd prefer a template based on something like the
Streamflow app, which has 7 layers, one assembler per layer, etc. Not
too simple, but still easy to fill in the blanks.
That would be nice, altho the danger in this approach is always that
devs will then try to stick to the template-approach for too long, when
they should instead switch approach or start building from scratch.
Sure, but if the code is copied, rather than as a library, then it will
always be possible to "hack away".
As an Eclipse user (IDEA seems very unusable, and it is not even free
either),
IDEA has a free Community Edition. It's what I use.
it would be nice to see an Eclipse Qi4j plugin. I think
something a-lá Maven plug-in for Eclipse, that one is extremely good
(whereas Gradle plug-in is not so good, hence I have to build Qi4j from
command line).
The most important for plugins is to rip out the part of Envisage that
takes a model and visualizes it. Then that could be wrapped into either
an IDEA, Eclipse or NetBeans plugin relatively easily, I think.
SQL-entitystore and SQL-indexing do that, except of course those still
need some improvement and especially documentation.
Yes, but I'd prefer to have the blobstore option as well, for performance.
* Getting a full stack. The main missing point to get a "full stack",
as it is, is the REST part. I have this, and can port it to Qi4j, so
that should be doable. Once that is in place we have a good end-to-end
stack for building apps, I think.
Don't use REST (yet). What exactly is 'full stack' then?
To me, when you can build a full webapp (yes, I'm using that as
baseline) with Qi4j, and not have to go outside too much for other
libraries to complement it.
Definetly doable, and should not give up. One thing that is "nice to
have", from *my* perspective, is to make the Core even more compact.
That is, remove the Entity/UnitOfWork concepts, since they are not
suitable for *all* applications out there. Put them in some
"default-entities" or something like that extension.
I would say they are core enough to be in there. *If* Entity goes, then
Value goes too, i.e. the whole "DDD" thing. Not sure there is enough
value in what's left, to be honest.
/Rickard
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
