Thank you Groza for your comments These are really helpful notes. Of course, that excerpted from the Spring data access ideas. And according to your statements about the overhead, that is completely right. But there is a change to shorten that little with the following 1. A new Delegator/DAO - whichever is closer to JDBC statements and result sets - implementation that works on POJO directly, not a GenericValue . 2. A new Service engine or Event handler that also operates on POJO directly, in the presentation side. If this is done, we are still facing a big challenge. * Flexibility of course Map, GenericValue is more flexible.. I don't know how much time this will take, but If you have the time please have a look. Also have a look at this cayenne project, in my opinion this can be an alternative to the entity engine https://cayenne.apache.org/ Thank you Groza All the best.
On Tue, Oct 1, 2024 at 9:22 PM Groza Danut <grozadanu...@gmail.com> wrote: > Hi Omar, > > Thank you for this contribution! > > I see that your proposal is quite similar to the way Spring JPA works, > using repositories for data access operations. I've actually used Spring > JPA a bit and I was quite satisfied with the architecture it has. > > I think your proposal is quite sane, however it has advantages as well as > disadvantages, so I would not recommend it for all cases. > > 1. It's more work to be done, since you need to map from POJO back and > forth. Probably the overhead is not justified where there is little > business logic. However the overhead might be justified when the business > logic is more complex and the POJO is used in multiple places. > > 2. This is strictly a Java approach. Would not work for Groovy scripts or > other services which are not Java. > > This being said, I believe your proposal has some real value. Here are > my thoughts: > > 1. ** Isolate the business logic (Operations in POJO or whatever), > and use OFBiz services only as orchestration service. > ** More Flexible for testing business logic. > > I 100% agree with your above statements in the proposal. Even if we still > use GenericValue with no POJO or mapping, I still believe extracting the > business logic from the services and using them only as orchestration would > be a real benefit in terms of code testability. > > 2. MapStruct is quite good as a mapper tool. It's lightweight, easy to use > and understand and quite fast. > Also a recommandation for reducing overhead: using Lombok for boilerplate > code(not sure how hard it is to integrate it in Ofbiz, so it might not be a > viable option). > > 3. I was actually thinking about a similar design for the new eInvoicing > plugin, so that might work as a POC for your proposal. I will definitely > use some ideas from your proposal when implementing it. > > Groza Danut > > On Tue, 1 Oct 2024, 16:01 Omar Abdullwahhab, <omar.abdullwah...@gmail.com> > wrote: > > > Hi Jacques, > > Thank you for following up > > here is the link > > > > > > > https://github.com/OmarAbdullwahhab/ofbiz-special-docs/blob/main/ofbiz_special_notes.adoc > > > > > > On Tue, Oct 1, 2024 at 2:43 PM Jacques Le Roux < > > jacques.le.r...@les7arts.com> > > wrote: > > > > > Hi Omar, > > > > > > Most of the time (say 98%) attachements don't pass, better using a > link. > > > > > > Jacques > > > > > > Le 01/10/2024 à 12:13, Omar Abdullwahhab a écrit : > > > > Hello OFBiz community, > > > > Attached is a development technique that can really simplify the > > process > > > of developing with > > > > OFBiz. > > > > Please have a look and your suggestions and recommendations are most > > > welcome. > > > > Thank you. > > > > -- > > > > Omar Abu-Arab > > > > Java Engineer* > > > > * > > > > * > > > > * > > > > > > > > -- > > Omar Abu-Arab > > Java Engineer > > > -- Omar Abu-Arab Java Engineer
