My reply/ideas inline.
Quoting Rickard Öberg <[email protected]>:
Hi,
I'd like to ask the question of what is the point with Qi4j, with
the software framework landscape being as it is. I'd very much like
your feedback on the questions and assertions below, to see if it
makes sense.
When me and Niclas started this project a long time ago, there were
a couple of different things that I personally wanted to address.
First of all it was the composite notion, that a domain object
should be able to use mixins, not only for code but also state.
Being able to use a roles-oriented approach significantly helps when
building real-world applications. I think the theory behind e.g. DCI
validates this quite a bit. Some of you know the backstory that in
2002 I tried using JBoss/EJB to build my first enterprise app
(SiteVision), and gave up after two weeks. It just wasn't possible.
And then I *had* to create the forerunner to Qi4j, just to "get
stuff done". I don't know how other developers can take the pain
involved with standard modeling tools and ORM's and all that
nonsense, but that was my experience anywa.
I fully agree with the last sentence. The current state of ORM's and
general modeling frameworks is appalling IMO, at least for Java
(except Qi4j of course) and C#.
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. :)
Another goal was to try and make AOP simpler. The ideas behind AOP
are good, but AspectJ, as the main implementation, is just too
complicated. The approach we adopted in Qi4j, with
concerns/sideeffects being registered on the composites, made it
much more explicit where these things go, and makes it in the end
easier to read the code. We now have the option of specifying these
in the assembly, as well as role types and mixins, so if you want
you can apply application-wide concerns quite easily. It all ends up
in the model anyway, which can be visualized.
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.
Then, I also wanted to support DDD better. DDD in itself is mainly a
process, which technically doesn't require a framework, but by
adopting some of its terminology, specifically Entity, Value,
UnitOfWork, etc. we make it easier for those who want to do that.
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.
That said, I have few other "application-owns-repository" -typed
projects, which successfully use the Entity/UnitOfWork -concept of
Qi4j. So, for those projects, the DDD of Qi4j works all fine.
And finally, I have always been frustrated with Worditectures, where
architectural layers and modules are only in a Word document, and
not in code. If these constraints are not enforced at runtime, it's
too easy to break these things, which is not so good.
Fully agree with that. And IMO Qi4j really does help with making it
easier to explicitly create and manage constraints, layers, and
modules of software architectures described in Word-documents. :)
So that's pretty much it. Good stuff. There's only one problem. It
takes quite some developer to understand one of these things, and a
very decent developer to understand all of it, and then a really
good developer to actually be able to implement it without making a
mess. David Leangen said to me that "Qi4j is 10 years ahead of its
time". In part that was true, as some of the theoretical background,
such as DCI, is only now being explored. A bigger issue is that the
level of developer it takes, at any point in time, to architect a
good Qi4j app is just too high. And then you need to teach the
developers on the team how to do it. I've done it now with my devs,
and I know Niclas has had great success on his side (in spite of
initial ruffling and sneering), so it is possible.
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 is also like an empty Word document. You can do anything, but
if you don't know where to start, it's a bit daunting. Now that I've
done Streamflow I can see a general pattern for how to do it, and
making another app like it would be much easier. In other words, one
of the things we're lacking is a decent template, or "scaffolding",
for apps, where you can more or less just "fill in the blanks". Most
frameworks these days do this, and it would make sense for us to
have this as well.
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.
Then there's the competition. What is the competition? The way I see
it you have JavaEE and Spring on the one end, and then
new-kids-on-the-block like Rails on the other. JavaEE is "standard",
and Spring is becoming a de-facto standard. Everybody "knows it",
and it shows up in job CVs and descriptions. The Rails guys seems to
be banking a lot on the "get up and running quickly" train. What
separates Qi4j from these frameworks is that, IF we have app
templates, not only would you be able to get up and running fast,
but AFTER the first version you would actually be able to grow
without too much pain. Support for refactoring, JMX and admin,
CircuitBreakers, and other evolution/admin features, gives us an
edge, along with the modeling possibilities that just aren't there
in other frameworks.
Never used Spring or JavaEE so no comments.
So what gives? My thoughts, and here's where I need your feedback,
is that Qi4j 2.0 should focus on simplicity and productivity, as
well as feature completeness. This means:
* Templates for common app structures, where developers "fill in the
blanks", e.g. "domain goes here, app services here, REST goes here".
Convention over configuration, but architecturally as well as on the
code. With the recent ClassScanner tool, this can even be "put these
kinds of classes in this package", and the ClassScanner can pick
them up automatically.
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.
* IDE plugins. We have Envisage now, but it is getting outdated. I
would like to change it into something like a IDEA plugin where you
can click "Refresh" (like the Gradle plugin), and it would show you
what your app looks like. Now that assembly is getting to a point
where you don't necessarily have to instantiate the app that is
created, this should be relatively easy
As an Eclipse user (IDEA seems very unusable, and it is not even free
either), 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).
* Support for traditional technologies, specifically on the DB side.
We need to support storing data in SQL databases easily, for the
simple reason that admins know how to manage and backup these
critters. As simple as that. They can also provide scaling features,
if necessary.
SQL-entitystore and SQL-indexing do that, except of course those still
need some improvement and especially documentation.
* More support for NOSQL. Adding e.g. CouchDB and MongoDB should be
trivial. I don't know how much these are actually used, but adding
them as EntityStores should a simple exercise, so why not?
Don't use NoSQL solutions, so no comments.
* Support for standard JSR's, such as 303 (Validation) and 330
(Injection), should be reasonably easy to do, and lowers the
learning curve on these things. Validation and Injection is a big
part of every day work, so this is important.
Haven't read those JSR's (yet), so no comments.
* Documentation. I've said this before, and I suck at doing it, but
it's still important. Documenting the basics, as well as common
patterns. I still feel like we need some kind of wiki-style website
for this to be really easy to do.
Seems Marc already got onto this. But yeah, Qi4j definetly needs more
documentation.
* 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?
So those are my thoughts on this. Is it doable? Or should I give up
on this? Is it possible to get any meaningful "marketshare" with
Qi4j, if v2.0 has all of the above? What is important? What is not
important? What do you guys think?
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 understand that this would make most devs add one more dependency to
projects, and would introduce significant changes to Core code-wise.
But, as for now, it is just a pity for me to watch those concepts
being totally unusable in the project I am working for. Additionally,
there is very little I can do to fix that, but if Core would provide
some kind of mechanism to easily implement custom Entity/UnitOfWork
concepts, it would be very nice.
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
