On 3 May 2011 20:34, Mark Diggory <mdigg...@atmire.com> wrote:
> Example: Hacking Domain Model Locally
>
> Right now, to add behavior to DSpace when Item state is altered has two
> options:
>
> a.) Alter the Item code
> b.) Write a consumer.
>
> The problem with (a) is that we need to maintain differences against core
> codebase and merge those differences over time, this is a problem when we
> have multiple projects / addons altering the core codebase. Which wins, how
> do we maintain both over time, altering the Domain Model is great until you
> have a larger community with lots of unique customizations
>
> The problem with (b) is that we can't participate in the transactional
> window and utilize the Context /database capabilities to complete our CRUD
> operations. We have to spawn our own transactional window after the current
> transaction and we cannot use foreign key constraints against the dspace
> data model tables to assure our database tables integrity, resulting in a
> lot of extra coding to roll our own integrity checking.
>
Let's not confuse how the subsystems currently work, with how they have to
work. Right now, when an event is 'fired', it is queued for execution after
the current context is committed. That doesn't mean we have to restrict
ourselves to only having those types of events - it's feasible to rework the
event system to allow 'immediate' consumers... where they are executed as
the event is fired, and where they participate in the active context.
There are some obvious side effects to that - people have to realise that
those consumers would need to:
a) execute promptly
b) take care not to throw exceptions unless they are absolutely sure they
should roll back the context
But then you have to do that for anything that you are executing 'in
context' - regardless of how it's been merged / linked / called. And it
doesn't have to be one or the other - we can still have delayed 'out of
context' consumers, as well as immediate 'in context' ones in the same
application.
And we can still use foreign key constraints in the 'immediate execution'
consumers. But, for any add ons, I would strongly argue that you should not
use foreign key constraints. Any add ins that start imposing database
integrity constraints are going to cause havoc during upgrades if we want /
need to make changes to the core model.
> I offer up that the benefits of the Domain Model and the Service Manager
> are that we be able to attain the "happy medium" where Addons can
> participate in the transactional window and contribute their own database
> tables into DSpace.
>
> By utilizing the SOA approach, we create chained DAO services that can
> participate in the transaction window. This was Jim Rutherfords original
> idea with the Stackable DAO.
>
>
> https://github.com/DSpace/DSpace/blob/dspace-dao-prototype/dspace-api/src/main/java/org/dspace/dao/StackableDAO.java
>
>
> https://github.com/DSpace/DSpace/blob/dspace-dao-prototype/dspace-api/src/main/java/org/dspace/content/dao/ItemDAOFactory.java
>
> What James was struggling with was the means to configure the stack of DAO
> that would participate in the transactional window. I think that with the
> Spring Service Manager, we now have an opportunity to answer his question.
>
>
I really didn't like the Stackable DAO design - I always viewed it as a
kludge for not having immediate / in-context consumers. My biggest complaint
is that it either makes or model more rigid, or it makes the add-in DAOs
fragile. Every change that gets made to the DAO contracts have to be
reflected in any add-in based off of it.
Compare that to the event notification mechanism - the API for passing
messages being consistent, and far less likely to break add-ins, even if we
make changes to what the DAOs do.
A secondary issue is that a stacked DAO is as near as damn it an interceptor
- and as interceptors are familiar design pattern, and widely used within
Spring. So if you did go this route [and configured it through Spring] then
it would be better to keep it consistent with standard concepts.
But the immediate execution event mechanism is better suited to your view of
having reliable add-ins.
G
------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network
management toolset available today. Delivers lowest initial
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
