Hi Jens, regarding integration: I agree with you that with an existing codebase the motivation to switch to qi4j is reduced by having to do a lot of rework.
But you still can adapt (Adapter) you existing codebase and have your DAO become imported Services. For binding in the web layer there is already some integration work for struts2 and wicket. But you could also use qi4j just in the middle have your main business logic divided into layers and modules and have it handle your business concerns effectively. Providing then services from qi4j to the view and consuming services/entitystores from persistence should be possible. There is also a Entity - JavaBean binding from Niclas and some service integration that he did in a real world project where the qi4j part had to integrate with existing code/architecture. What I find also very important to adoption is rather in the business domain. What are the means / tools / patterns to take business knowledge and transform it into the appropriate ddd / qi4j constructs. How to help your customer facing developers / BAs to take the knowledge directly apply it to the application and show the customer what this means - e.g. the visualizer could help to make things in the core domain of your application transparent to the customer. You know this black box where no customer ever knows / wants to know whats happening in there. So far they have mostly been focusing on the UI / Database because there they can see things they know and expect. have fun, Michael Jens Schumann schrieb: > Hi all, > > Here we go with part 2 from 3. > > Part 2: Non-technical feedback > > 2.1 COP/Qi4J - a new thought paradigm and programming model > > One of the major issues regarding Qi4J mass adoption could be the different > thought paradigm and programming model. It requires - as written in part one > - a strong foundation in domain driven design (which requires good OO > skills) and a transition to COP. > > During my tests it took some effort to get used to COP. And I believe - > similar to David Leangen - that you have to have a lot of time to understand > the implications of certain design decisions. I even had a hard time to find > the right names for fragments (interfaces)... > > Could certain design blueprints help? Do we need design recommendations that > help others identify fragments? I don't know. > > What do you think how much time it will take for the transition from > infrastructure based OOP (as seen in Java today) to COP/Qi4J? I would say at > least two medium size projects. Does 1 to 1.5 years sound familiar? > > I am not kidding. When I was playing around with Qi4J it felt like writing > the first lines of basic again. And it still feels uncomfortable in certain > areas. Is this a valid fragment? How do I navigate across my domain? How do > I define default state for this entity attribute? ... > > Looks like I am still at the beginning of the steep learning curve;). > > 2.2 Qi4J - the all or nothing approach > > Please correct me if I am wrong: I believe Qi4J can be a good option for a > project that starts from scratch. But once you have a significant investment > in technology that differs from Qi4j it will be very very hard to introduce > Qi4J (and with in COP). > > A simple example: How do I leverage my existing application code base that > uses this large relational database model just like 95% percent of all Java > applications out there? Do I need to throw away my OR mapping and DAO code? > Or maintain Qi4J and traditional access code in parallel? > > "Yes" could be a valid answer, since the COP model could be too different > from the traditional model. But if we say yes .. you know what I am trying > to say. And no, I don't want to discuss RDBMS vs ... again. > > But if we want Qi4J to succeed we definitely need to think about incremental > application migration. And this - in my opinion - includes RDBMS support as > first class citizen. > > 2.3 Qi4J maturity > > I just tried to compile my Qi4J example from November 2008. Well. After > changing almost all Qi4J imports and a few class names it works again. > Unfortunately this happened the last 5-6 months every time I looked into my > example. > > I personally believe Qi4J started to stabilize a lot. The changes however > tend to break backwards compatibility regularly. > > Should we better call Qi4J "unstable"? > > Yes?! No problem. But then we should jump on my suggestion from part one and > talk more about COP while stating that the only freely available > implementation is still work in progress. > > 2.4 Focus on solutions > > The list of options in Qi4J lib and Qi4J extension is impressive. What might > be missing are "solutions" that can be extended or improved. What I am > talking about are answers to: > > How do I implement a server application that can be access remotely? > How do I implement a Swing client that talks to my server? > > Same applies for web applications. As far as I know web application support > is not available yet. Initially it might be enough to focus on one solution. > Don't ask me why I think web application support might be the killer > feature;). > > In general I think it is time to move the focus from "What should we add?" > to "How do I do...?". See "Getting started" in part three for further > comments on this. > > > So. This was part two. I have to skip the last, more technical part for now. > Should show up later the day. > > So far, > Jens > > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
