entity engine - separation of concerns

[chris snow]

I've been working on separating the entity engine from the framework
for a project I am working on.  It is quite slow going as classes seem
to be doing more that one task.

For example, ModelEntity is quite tightly coupled to ModelReader.  I'm
assuming ModelEntity is primarily responsible for representing a model
of an entity, however, it is also mixed with logic for building itself
from the xml definition.  For me it seems like the build logic should
be moved to another class, e.g. ModelEntityReaderBuilder that is
responsible for building the ModelEntity from the ModelReader?

Cheers,

Chris

[Adrian Crum]

Separating model building logic from the model classes has been
discussed before. I have toyed with the idea of creating a branch to
experiment with that and other model changes.

-Adrian

On 9/27/2010 11:08 AM, chris snow wrote:

> I've been working on separating the entity engine from the framework
> for a project I am working on.  It is quite slow going as classes seem
> to be doing more that one task.
>
> For example, ModelEntity is quite tightly coupled to ModelReader.  I'm
> assuming ModelEntity is primarily responsible for representing a model
> of an entity, however, it is also mixed with logic for building itself
> from the xml definition.  For me it seems like the build logic should
> be moved to another class, e.g. ModelEntityReaderBuilder that is
> responsible for building the ModelEntity from the ModelReader?
>
> Cheers,
>
> Chris
>

[Adam Heath-2]

On 09/27/2010 01:08 PM, chris snow wrote:

> I've been working on separating the entity engine from the framework
> for a project I am working on.  It is quite slow going as classes seem
> to be doing more that one task.
>
> For example, ModelEntity is quite tightly coupled to ModelReader.  I'm
> assuming ModelEntity is primarily responsible for representing a model
> of an entity, however, it is also mixed with logic for building itself
> from the xml definition.  For me it seems like the build logic should
> be moved to another class, e.g. ModelEntityReaderBuilder that is
> responsible for building the ModelEntity from the ModelReader?

Yes.  ModelEntity should just be a datastore of the definition of an
entity.  Different readers can then product such objects using
whatever form they want.

[chris snow]

Thanks for the feedback Adam and Adrian.

I don't think I'm going to get anywhere very quickly with coding this
myself (it's taking too long to split it all apart) so I'll raise this
as a JIRA improvement so we have a record.

[Scott Gray-2]

Please excuse my ignorance, but aside from beauty in design what would the tangible benefit of such a change be?  What would it allow you to achieve that isn't possible right now (and that you actually have a use case for)?

I have no problem with refactoring and improving designs but I'm also a fan of not fixing what isn't broken.

Thanks
Scott

HotWax Media
http://www.hotwaxmedia.com

On 28/09/2010, at 7:13 AM, Adrian Crum wrote:

> Separating model building logic from the model classes has been discussed before. I have toyed with the idea of creating a branch to experiment with that and other model changes.
>
> -Adrian
>
> On 9/27/2010 11:08 AM, chris snow wrote:
>> I've been working on separating the entity engine from the framework
>> for a project I am working on.  It is quite slow going as classes seem
>> to be doing more that one task.
>>
>> For example, ModelEntity is quite tightly coupled to ModelReader.  I'm
>> assuming ModelEntity is primarily responsible for representing a model
>> of an entity, however, it is also mixed with logic for building itself
>> from the xml definition.  For me it seems like the build logic should
>> be moved to another class, e.g. ModelEntityReaderBuilder that is
>> responsible for building the ModelEntity from the ModelReader?
>>
>> Cheers,
>>
>> Chris
>>

[chris snow]

Hi Scott,

Some of the problems with the current design being tightly coupled:

- maintainability
- extensibility
- testability

Some use cases, that would be easier with the re-design:

1) Improved ofbiz update management (i.e. patches), by:
- Moving the configuration of the entity engine to a separate folder.
- Making the entity engine an external component, e.g. a jar file.
2) Dynamic changes to entity models.
3) Re-use the entity engine outside of ofbiz.

You are right that the entity engine isn't broken, and I accept that
the above changes are possible with the current design - they are just
harder to do with the current design.

[Adam Heath-2]

Scott Gray wrote:
> Please excuse my ignorance, but aside from beauty in design what would the tangible benefit of such a change be?  What would it allow you to achieve that isn't possible right now (and that you actually have a use case for)?
>
> I have no problem with refactoring and improving designs but I'm also a fan of not fixing what isn't broken.

It would help with my sql code(framework/sql).  It's not possible to
create certain kinds of on-the-fly models, because the existing
classes do too much in their constructors, without allowing for
external setup.

If they are rewritten to use an external reader, then having an
alternative method to construct them becomes simpler.

[Adam Heath-2]

chris snow wrote:

> Hi Scott,
>
> Some of the problems with the current design being tightly coupled:
>
> - maintainability
> - extensibility
> - testability
>
> Some use cases, that would be easier with the re-design:
>
> 1) Improved ofbiz update management (i.e. patches), by:
> - Moving the configuration of the entity engine to a separate folder.
> - Making the entity engine an external component, e.g. a jar file.
> 2) Dynamic changes to entity models.
> 3) Re-use the entity engine outside of ofbiz.
>
> You are right that the entity engine isn't broken, and I accept that
> the above changes are possible with the current design - they are just
> harder to do with the current design.

It's not broken, of course.  It actually works.  But, you are wanting
new features(ones I would like to see too).  So, the discussion needs
to show the features as being useful.  But I don't want to see this
devolve into wanting a *perfect* description of the use case; it may
become obvious when the implementation is closer to being done.

[BJ Freeman]

one of the main features that drew me to ofbiz was the simplisity of design.
if I changed and entity, the data related to that was displayed on a
page with no further work.
so in that light how does what is being proposed effect this.

Adam Heath sent the following on 9/27/2010 7:21 PM:

> Scott Gray wrote:
>> Please excuse my ignorance, but aside from beauty in design what would the tangible benefit of such a change be?  What would it allow you to achieve that isn't possible right now (and that you actually have a use case for)?
>>
>> I have no problem with refactoring and improving designs but I'm also a fan of not fixing what isn't broken.
>
> It would help with my sql code(framework/sql).  It's not possible to
> create certain kinds of on-the-fly models, because the existing
> classes do too much in their constructors, without allowing for
> external setup.
>
> If they are rewritten to use an external reader, then having an
> alternative method to construct them becomes simpler.
>

[BJ Freeman]

have you given any thought to the Config files and multitenant

=========================
BJ Freeman
Strategic Power Office with Supplier Automation  <http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com  <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist

Chat  Y! messenger: bjfr33man


chris snow sent the following on 9/27/2010 6:42 PM:

> Hi Scott,
>
> Some of the problems with the current design being tightly coupled:
>
> - maintainability
> - extensibility
> - testability
>
> Some use cases, that would be easier with the re-design:
>
> 1) Improved ofbiz update management (i.e. patches), by:
> - Moving the configuration of the entity engine to a separate folder.
> - Making the entity engine an external component, e.g. a jar file.
> 2) Dynamic changes to entity models.
> 3) Re-use the entity engine outside of ofbiz.
>
> You are right that the entity engine isn't broken, and I accept that
> the above changes are possible with the current design - they are just
> harder to do with the current design.
>

[Scott Gray-2]

On 28/09/2010, at 3:21 PM, Adam Heath wrote:

> Scott Gray wrote:
>> Please excuse my ignorance, but aside from beauty in design what would the tangible benefit of such a change be?  What would it allow you to achieve that isn't possible right now (and that you actually have a use case for)?
>>
>> I have no problem with refactoring and improving designs but I'm also a fan of not fixing what isn't broken.
>
> It would help with my sql code(framework/sql).  

Might be a bad example, I'm pretty sure you're the only person on the planet that has any idea what framework/sql does.

> It's not possible to
> create certain kinds of on-the-fly models, because the existing
> classes do too much in their constructors, without allowing for
> external setup.
>
> If they are rewritten to use an external reader, then having an
> alternative method to construct them becomes simpler.

I understand why refactoring would make this easier, I just don't understand what purpose being able to create "on-the-fly models" would serve.

[Scott Gray-2]

On 28/09/2010, at 3:23 PM, Adam Heath wrote:

> chris snow wrote:
>> Hi Scott,
>>
>> Some of the problems with the current design being tightly coupled:
>>
>> - maintainability
>> - extensibility
>> - testability
>>
>> Some use cases, that would be easier with the re-design:
>>
>> 1) Improved ofbiz update management (i.e. patches), by:
>> - Moving the configuration of the entity engine to a separate folder.
>> - Making the entity engine an external component, e.g. a jar file.
>> 2) Dynamic changes to entity models.
>> 3) Re-use the entity engine outside of ofbiz.
>>
>> You are right that the entity engine isn't broken, and I accept that
>> the above changes are possible with the current design - they are just
>> harder to do with the current design.
>
> It's not broken, of course.  It actually works.  But, you are wanting
> new features(ones I would like to see too).  So, the discussion needs
> to show the features as being useful.  But I don't want to see this
> devolve into wanting a *perfect* description of the use case; it may
> become obvious when the implementation is closer to being done.

I'm not looking for perfect examples, any real one would probably do.

[Scott Gray-2]

Hi Chris,

Thanks for the response, comments inline.

On 28/09/2010, at 2:42 PM, chris snow wrote:

> Hi Scott,
>
> Some of the problems with the current design being tightly coupled:
>
> - maintainability
> - extensibility
> - testability

This all sounds nice but I still fail to see how these things would be achieved by decoupling the ModelReader and ModelEntity classes.  
This was the situation I'm asking specifically about, the discussion so far seems to have gone like this:
- You asked why they were tightly coupled and suggested that they shouldn't be (without saying why)
- Adrian mentioned that it had been discussed before (but what does that actually mean? What was the outcome?)
- Adam suggested that by decoupling you could then use other mechanisms to produce ModelEntity instances (great! What's the use case, why would you want to?)
- You've responded to my query with the items above, which lets be honest are so vague as to actually mean nothing.  And the items below, which I'll respond to inline:

> Some use cases, that would be easier with the re-design:
>
> 1) Improved ofbiz update management (i.e. patches), by:
> - Moving the configuration of the entity engine to a separate folder.

By looking at EntityConfigUtil, it appears to me that the only requirement for configuration is that entityengine.xml is somewhere on the classpath.  The actual folder appears irrelevant.

> - Making the entity engine an external component, e.g. a jar file.

Not sure how this blocks that.

> 2) Dynamic changes to entity models.

Sounds like a pretty big can of worms, what's the use case?  But even then I don't see how the ModelReader gets in the way.

> 3) Re-use the entity engine outside of ofbiz.

Not sure whats actually blocking that from the discussion so far

> You are right that the entity engine isn't broken, and I accept that
> the above changes are possible with the current design - they are just
> harder to do with the current design.

I'm not trying to argue with you or even say that you're wrong, I'm simply trying to see the forest for the trees.  Normally when I decide to refactor something it's because I want to add a new feature that I can't achieve (or achieve cleanly) with the existing design, and I'm just trying to understand what that feature is specifically for this case and the jira issue that's been created.

[David E. Jones-2]

Thanks for your comments Scott. There is a lot of ugly code in OFBiz that has been justified with these sorts of terms and arguments, to the point that I cringe when I see them now.

Personally I like the current inherent externability and general overalicity of the framework. Actually, as far as coding patterns go IMO it would be nice to go back in time a bit on certain things...

-David



On Sep 27, 2010, at 8:37 PM, Scott Gray wrote:

> Hi Chris,
>
> Thanks for the response, comments inline.
>
> On 28/09/2010, at 2:42 PM, chris snow wrote:
>
>> Hi Scott,
>>
>> Some of the problems with the current design being tightly coupled:
>>
>> - maintainability
>> - extensibility
>> - testability
>
> This all sounds nice but I still fail to see how these things would be achieved by decoupling the ModelReader and ModelEntity classes.  
> This was the situation I'm asking specifically about, the discussion so far seems to have gone like this:
> - You asked why they were tightly coupled and suggested that they shouldn't be (without saying why)
> - Adrian mentioned that it had been discussed before (but what does that actually mean? What was the outcome?)
> - Adam suggested that by decoupling you could then use other mechanisms to produce ModelEntity instances (great! What's the use case, why would you want to?)
> - You've responded to my query with the items above, which lets be honest are so vague as to actually mean nothing.  And the items below, which I'll respond to inline:
>
>> Some use cases, that would be easier with the re-design:
>>
>> 1) Improved ofbiz update management (i.e. patches), by:
>> - Moving the configuration of the entity engine to a separate folder.
>
> By looking at EntityConfigUtil, it appears to me that the only requirement for configuration is that entityengine.xml is somewhere on the classpath.  The actual folder appears irrelevant.
>
>> - Making the entity engine an external component, e.g. a jar file.
>
> Not sure how this blocks that.
>
>> 2) Dynamic changes to entity models.
>
> Sounds like a pretty big can of worms, what's the use case?  But even then I don't see how the ModelReader gets in the way.
>
>> 3) Re-use the entity engine outside of ofbiz.
>
> Not sure whats actually blocking that from the discussion so far
>
>> You are right that the entity engine isn't broken, and I accept that
>> the above changes are possible with the current design - they are just
>> harder to do with the current design.
>
> I'm not trying to argue with you or even say that you're wrong, I'm simply trying to see the forest for the trees.  Normally when I decide to refactor something it's because I want to add a new feature that I can't achieve (or achieve cleanly) with the existing design, and I'm just trying to understand what that feature is specifically for this case and the jira issue that's been created.
>

[chris snow]

Hi Scott,

Sorry for being a bit vague with my initial response.

The last few nights I have been working on separating the entity
engine so it could be used outside of ofbiz, but it is proving to be
very difficult due to the entity engine's dependency (coupling) on the
ofbiz configuration code.

So basically, I wanted to look at the entity engine as a standalone
piece of functionality (i.e. managing interaction with a database).
However, the tight coupling makes it difficult to isolate the core
functionality of the entity engine without first unwrapping a layer of
code that configures the entity engine (i.e. ModelReader,
ComponentConfig, etc).  Having to first understand the configuration
layer has an impact on maintainability of the entity engine - it is
difficult to make changes to the core functionality on the entity
engine without first having to wrestle with the configuration layer.
The same argument goes for extensability and testability.

Many thanks,

Chris

[chris snow]

There's obviously two camps on the proposals, so who gets the overall
say in what changes make it into the framework?

I.e. Would I be wasting my time working on separating ModelEntity and
ModelReader (and entity engine core functionality from its
configuration)?

[Scott Gray-2]

It's irrelevant to discuss who has the final say before everything has been said.  And please keep in mind that I haven't actually spoken out against the proposal, I've only attempted to get its proponents to do a better job of justifying it.

I can't tell you what would be a waste of your time but personally I don't work on any contributions that I can't get a consensus for.  OFBiz is such a huge project that taking that approach never leaves me short of things to work on anyway.  Even if you were to get a consensus there is no guarantee that it would be committed in a timely manner, there's plenty of contributions sitting in jira uncommitted simply because of their size or complexity and a lack of time for anyone to review and commit them.

Regards
Scott

On 28/09/2010, at 8:24 PM, chris snow wrote:

> There's obviously two camps on the proposals, so who gets the overall
> say in what changes make it into the framework?
>
> I.e. Would I be wasting my time working on separating ModelEntity and
> ModelReader (and entity engine core functionality from its
> configuration)?

[Scott Gray-2]

On 28/09/2010, at 8:04 PM, chris snow wrote:

> Hi Scott,
>
> Sorry for being a bit vague with my initial response.
>
> The last few nights I have been working on separating the entity
> engine so it could be used outside of ofbiz, but it is proving to be
> very difficult due to the entity engine's dependency (coupling) on the
> ofbiz configuration code.

It's been a few years but I'm sure there used to be blog posts about doing this exact thing and I don't remember it being so difficult.  I think you're concern below about the dependency on ComponentConfig (and I assume the entire base package) begins to clarify why this is difficult.

> So basically, I wanted to look at the entity engine as a standalone
> piece of functionality (i.e. managing interaction with a database).
> However, the tight coupling makes it difficult to isolate the core
> functionality of the entity engine without first unwrapping a layer of
> code that configures the entity engine (i.e. ModelReader,
> ComponentConfig, etc).  

I think we found something concrete!  There is a very light dependency on ComponentConfig in the ModelReader class, but why is that a problem?  Is it so bad for the entity engine to also depend on a base jar?  Attempting to remove those dependencies misses the whole point of OFBiz being a framework, the entity engine not being able to use the base OFBiz utility classes just makes no sense to me.

Also, keep in mind that you don't actually have to use ofbiz-component files in order to define entity model definition locations, this can be done directly within the entityengine.xml file itself.  The ModelReader constructor doesn't actually require ComponentConfig.getAllEntityResourceInfos(String) to return anything, which essentially means that the entity engine will still work just fine without any components having been defined.