You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ojb-dev@db.apache.org by Brian McCallister <mc...@forthillcompany.com> on 2003/09/30 21:38:11 UTC
ODMG Tutorial Take 1
Just checked in take one on the new ODMG tutorial. I am *not* an ODMG
expert, or even, in my opinion, proficient with the ODMG API so I would
very much appreciate feedback on idiomatic usage etc.
I copied most of the usage from tutorial2, but have a few direct
questions.
Why persist new object via a write lock instead of
Database.makePersistent()?
In the update example, is the lock required in order to change the
persistent version of the object?
Etc.
As it is only in CVS, I have a copy up at
http://kasparov.skife.org/ojb/odmg-tutorial.html
Thanks,
Brian
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: ODMG Tutorial Take 1
Posted by Thomas Mahler <th...@web.de>.
Hi all,
I agree with Brian, we decided to change the tutorials to be more
focussed on the actual usage of the APIs and not to confuse the user
with design of the original tutorial apps.
This is what a lot of users asked for.
Of course this is only half of the story. To build real applications we
have to talk about building model layers, Data access patterns and
application layering in general.
OJB is architecturally neutral in so far as it can be used in many
different architecures (e.g. with or without DAOs, with or withous DTO,
with long or short transactions, in 2-, or n-tier apps, within
servlets, within SessionBeans, within EntityBeans, as a JCA resource,
etc. etc.).
Of course it would be nice to have samples and explanations for all
these different things. But I guess you can easily fill a whole book
with this material...
Of course I'd be happy to have such a comprehensive documentation on our
site. But with a realistic estimate of the available resources I'm not
optimistic that we will see this soon
We already have a page where we point to good books covering a lot of
those topics (http://db.apache.org/ojb/links.html)
Maybe it's a good idea to include more links to books and resources that
cover the mentions topics.
cheers,
Thomas
Brian McCallister wrote:
> Philippe,
>
> I would like to pick up on a thought you presented -- building a good
> architecture which includes an O/R mapping layer. I have had mixed
> thoughts about including that in the OJB docs. I have thought about it,
> but on the other hand OJB is *not* a domain model framework, it is an
> O/R mapping tool. Many other people present excellent domain modeling
> and application architecture ideas (I am reading Eric Evan's
> /Domain-Driven Design/ right now, so it comes to mind) and are able to
> explain concepts in a much clearer manner than I think I could.
>
> One of the problems with the current tutorials is that they are too well
> designed as applications. Common code is factored out, actions are
> encapsulated, etc. They do not demonstrate OJB as clearly as is desired
> because of this. I am purposefully doing naive-procedural style
> tutorials (ie, calling fine grained stuff instead of passing data
> structures around) because they show OJB much more clearly.
>
> All this aside, I frequently feel there *should* be something about good
> design in the OJB docs, but I don't want to simply duplicate what
> exists. Perhaps pointers and discussions of where OJB fits into the en
> vogue design ideas has a good place.
>
> Your thoughts?
>
> -Brian
>
> On Wednesday, October 1, 2003, at 04:33 AM, Philippe Hacquin wrote:
>
>> Hi Thomas,
>>
>> just my point of view regarding "long transactions" and the tutorial.
>> When I started using OJB a few months ago, I would have liked to
>> quickly get a clear view of a good software architecture for my web
>> application. I think the ODMG tutorial should promote in a few words a
>> good separation between the usual three tiers of a web app. The
>> presentation layer should not deal with objects pertaining to the data
>> layer, they should instead work on value objects. The business logic
>> layer should handle requests in a transaction to the data layer, on
>> behalf of the presentation layer, and return responses in value objects.
>> When the data has been updated in the presentation layer, the business
>> logic should receive it in a value object, then update it by a request
>> in the data layer, in another transaction.
>>
>> tx.markDirty() should also be avoided if you do not want to introduce
>> in your app an adherence to the OJB implementation of ODMG, but I
>> agree this is a matter of concern for the developer of an application,
>> not for OJB developers. ;-)
>>
>> Chuck Cavaness clearly explains these patterns in "Programming Jakarta
>> Struts", but unfortunately he does not dive much into using OJB and
>> the ODMG API for updates.
>>
>> So, in my opinion, "tx.markDirty(product)" could be in a FAQ, but not
>> in the tutorial. (BTW, I guess you meant TransactionImpl instead of
>> TransactionExt).
>>
>> Thomas Mahler wrote:
>>
>>> [...]
>>
>>
>>> Another thing that I'd like to see added in the update section is
>>> about long transactions. A lot of users are using the odmg API in web
>>> applications, where business objects are modified in the GUI and then
>>> persisted by a DAO. So Objects are not modified within a transaction.
>>> This is really FAQ and I'd be happy if it'd be answered in the tutorial!
>>>
>>> to make sure that OJB can still persist the changes made outside the
>>> transaction we need the following code:
>>>
>>> public static void persistChanges(Product product)
>>> {
>>> Implementation impl = OJB.getInstance();
>>> TransactionExt tx = (TransactionExt) impl.newTransaction();
>>> tx.markDirty(product);
>>> tx.commit();
>>> }
>>>
>>> where TransactionExt is an OJB specific extension to the ODMG
>>> Transaction interface that contains helper methods to obtain the
>>> underlying PB or to mark objects for DELETE or UPDATE.
>>>
>>> thanks,
>>> Thomas
>>>
>>>
>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: ODMG Tutorial Take 1
Posted by Philippe Hacquin <ha...@wanadoo.fr>.
Hi Brian,
I agree with you that OJB tutorials do not have to be technical
references for n-tier apps design, that's why I suggested "promote in a
few words". What I meant in my previous post is that a tutorial, which
is targeted to newcomers, should not mention techniques that make look
OJB less smarter than it really is.
I can remember of a post Thomas sent on the user's list a few weeks ago,
that stated something like "with ODMG, objects retrieved in a
transaction are not guaranteed to be still alive outside the
transaction" (unless I misunderstood him). If you follow that advice,
in the context of a "long transaction" and a web app, you should use
value objects, and not work on those data objects retrieved during the
transaction. Hence, you don't have to use tx.markDirty(), which is
beside that not a good rule of design, because it makes your app
dependent on a particular implementation of ODMG.
Well, let's say that a simple web app shipped with OJB, as an example of
using the ODMG API, would make things much more easy for everyone new to
OJB. No need for the tutorial to look extensively at the code, just a
link to the code would be OK. No need to get a particular framework such
as Struts involved, too, just one servlet and two JSPs for the
presentation tier (and, sure, the value object), tested in Tomcat,
that's all. I can contribute for this topic, if needed.
For publicly available pointers about value objects, I just have one in
mind for the moment. Sun has a good description of the value object in
their J2EE patterns catalog
(http://java.sun.com/blueprints/corej2eepatterns/Patterns/TransferObject.html).
But unfortunately it is presented as a response to the problem of the
overhead for the objects in a web container calling remote EJBs in their
own container; this is rather boring for people that have no or few
knowledge about EJBs, and that have spent a whole day reading OJB
documentation.
Brian McCallister wrote:
> Philippe,
>
> I would like to pick up on a thought you presented -- building a good
> architecture which includes an O/R mapping layer. I have had mixed
> thoughts about including that in the OJB docs. I have thought about
> it, but on the other hand OJB is *not* a domain model framework, it is
> an O/R mapping tool. Many other people present excellent domain
> modeling and application architecture ideas (I am reading Eric Evan's
> /Domain-Driven Design/ right now, so it comes to mind) and are able to
> explain concepts in a much clearer manner than I think I could.
>
> One of the problems with the current tutorials is that they are too
> well designed as applications. Common code is factored out, actions
> are encapsulated, etc. They do not demonstrate OJB as clearly as is
> desired because of this. I am purposefully doing naive-procedural
> style tutorials (ie, calling fine grained stuff instead of passing
> data structures around) because they show OJB much more clearly.
>
> All this aside, I frequently feel there *should* be something about
> good design in the OJB docs, but I don't want to simply duplicate what
> exists. Perhaps pointers and discussions of where OJB fits into the en
> vogue design ideas has a good place.
>
> Your thoughts?
>
> -Brian
>
> On Wednesday, October 1, 2003, at 04:33 AM, Philippe Hacquin wrote:
>
>> Hi Thomas,
>>
>> just my point of view regarding "long transactions" and the tutorial.
>> When I started using OJB a few months ago, I would have liked to
>> quickly get a clear view of a good software architecture for my web
>> application. I think the ODMG tutorial should promote in a few words
>> a good separation between the usual three tiers of a web app. The
>> presentation layer should not deal with objects pertaining to the
>> data layer, they should instead work on value objects. The business
>> logic layer should handle requests in a transaction to the data
>> layer, on behalf of the presentation layer, and return responses in
>> value objects.
>> When the data has been updated in the presentation layer, the
>> business logic should receive it in a value object, then update it by
>> a request in the data layer, in another transaction.
>>
>> tx.markDirty() should also be avoided if you do not want to introduce
>> in your app an adherence to the OJB implementation of ODMG, but I
>> agree this is a matter of concern for the developer of an
>> application, not for OJB developers. ;-)
>>
>> Chuck Cavaness clearly explains these patterns in "Programming
>> Jakarta Struts", but unfortunately he does not dive much into using
>> OJB and the ODMG API for updates.
>>
>> So, in my opinion, "tx.markDirty(product)" could be in a FAQ, but not
>> in the tutorial. (BTW, I guess you meant TransactionImpl instead of
>> TransactionExt).
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
>> For additional commands, e-mail: ojb-dev-help@db.apache.org
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: ODMG Tutorial Take 1
Posted by Brian McCallister <mc...@forthillcompany.com>.
Philippe,
I would like to pick up on a thought you presented -- building a good
architecture which includes an O/R mapping layer. I have had mixed
thoughts about including that in the OJB docs. I have thought about it,
but on the other hand OJB is *not* a domain model framework, it is an
O/R mapping tool. Many other people present excellent domain modeling
and application architecture ideas (I am reading Eric Evan's
/Domain-Driven Design/ right now, so it comes to mind) and are able to
explain concepts in a much clearer manner than I think I could.
One of the problems with the current tutorials is that they are too
well designed as applications. Common code is factored out, actions are
encapsulated, etc. They do not demonstrate OJB as clearly as is desired
because of this. I am purposefully doing naive-procedural style
tutorials (ie, calling fine grained stuff instead of passing data
structures around) because they show OJB much more clearly.
All this aside, I frequently feel there *should* be something about
good design in the OJB docs, but I don't want to simply duplicate what
exists. Perhaps pointers and discussions of where OJB fits into the en
vogue design ideas has a good place.
Your thoughts?
-Brian
On Wednesday, October 1, 2003, at 04:33 AM, Philippe Hacquin wrote:
> Hi Thomas,
>
> just my point of view regarding "long transactions" and the tutorial.
> When I started using OJB a few months ago, I would have liked to
> quickly get a clear view of a good software architecture for my web
> application. I think the ODMG tutorial should promote in a few words a
> good separation between the usual three tiers of a web app. The
> presentation layer should not deal with objects pertaining to the data
> layer, they should instead work on value objects. The business logic
> layer should handle requests in a transaction to the data layer, on
> behalf of the presentation layer, and return responses in value
> objects.
> When the data has been updated in the presentation layer, the business
> logic should receive it in a value object, then update it by a request
> in the data layer, in another transaction.
>
> tx.markDirty() should also be avoided if you do not want to introduce
> in your app an adherence to the OJB implementation of ODMG, but I
> agree this is a matter of concern for the developer of an application,
> not for OJB developers. ;-)
>
> Chuck Cavaness clearly explains these patterns in "Programming Jakarta
> Struts", but unfortunately he does not dive much into using OJB and
> the ODMG API for updates.
>
> So, in my opinion, "tx.markDirty(product)" could be in a FAQ, but not
> in the tutorial. (BTW, I guess you meant TransactionImpl instead of
> TransactionExt).
>
> Thomas Mahler wrote:
>
>> [...]
>
>> Another thing that I'd like to see added in the update section is
>> about long transactions. A lot of users are using the odmg API in web
>> applications, where business objects are modified in the GUI and then
>> persisted by a DAO. So Objects are not modified within a transaction.
>> This is really FAQ and I'd be happy if it'd be answered in the
>> tutorial!
>>
>> to make sure that OJB can still persist the changes made outside the
>> transaction we need the following code:
>>
>> public static void persistChanges(Product product)
>> {
>> Implementation impl = OJB.getInstance();
>> TransactionExt tx = (TransactionExt) impl.newTransaction();
>> tx.markDirty(product);
>> tx.commit();
>> }
>>
>> where TransactionExt is an OJB specific extension to the ODMG
>> Transaction interface that contains helper methods to obtain the
>> underlying PB or to mark objects for DELETE or UPDATE.
>>
>> thanks,
>> Thomas
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: ODMG Tutorial Take 1
Posted by Philippe Hacquin <ph...@voila.fr>.
Hi Thomas,
just my point of view regarding "long transactions" and the tutorial.
When I started using OJB a few months ago, I would have liked to quickly
get a clear view of a good software architecture for my web
application. I think the ODMG tutorial should promote in a few words a
good separation between the usual three tiers of a web app. The
presentation layer should not deal with objects pertaining to the data
layer, they should instead work on value objects. The business logic
layer should handle requests in a transaction to the data layer, on
behalf of the presentation layer, and return responses in value objects.
When the data has been updated in the presentation layer, the business
logic should receive it in a value object, then update it by a request
in the data layer, in another transaction.
tx.markDirty() should also be avoided if you do not want to introduce in
your app an adherence to the OJB implementation of ODMG, but I agree
this is a matter of concern for the developer of an application, not
for OJB developers. ;-)
Chuck Cavaness clearly explains these patterns in "Programming Jakarta
Struts", but unfortunately he does not dive much into using OJB and the
ODMG API for updates.
So, in my opinion, "tx.markDirty(product)" could be in a FAQ, but not in
the tutorial. (BTW, I guess you meant TransactionImpl instead of
TransactionExt).
Thomas Mahler wrote:
> [...]
> Another thing that I'd like to see added in the update section is
> about long transactions. A lot of users are using the odmg API in web
> applications, where business objects are modified in the GUI and then
> persisted by a DAO. So Objects are not modified within a transaction.
> This is really FAQ and I'd be happy if it'd be answered in the tutorial!
>
> to make sure that OJB can still persist the changes made outside the
> transaction we need the following code:
>
> public static void persistChanges(Product product)
> {
> Implementation impl = OJB.getInstance();
> TransactionExt tx = (TransactionExt) impl.newTransaction();
> tx.markDirty(product);
> tx.commit();
> }
>
> where TransactionExt is an OJB specific extension to the ODMG
> Transaction interface that contains helper methods to obtain the
> underlying PB or to mark objects for DELETE or UPDATE.
>
> thanks,
> Thomas
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org
Re: ODMG Tutorial Take 1
Posted by Thomas Mahler <th...@web.de>.
Hi again Brian,
Brian McCallister wrote:
> Just checked in take one on the new ODMG tutorial. I am *not* an ODMG
> expert, or even, in my opinion, proficient with the ODMG API so I would
> very much appreciate feedback on idiomatic usage etc.
I like your new tutorial very much. you are presenting the essential API
elements in a very clear and concise way!
> I copied most of the usage from tutorial2, but have a few direct questions.
>
> Why persist new object via a write lock instead of
> Database.makePersistent()?
Both ways will work. I think as you use Database.deletePersistent() in
the "Deleting persistent objects" section it would be more consistent to
use db.makePersistent() for storing new objects.
Maybe it's a good idea to present both ways. It'll be only few lines of
code.
> In the update example, is the lock required in order to change the
> persistent version of the object?
No, it's no required. OJB will detect the changes during tx.commit().
But if you want to make sure that the current thread has a write lock on
that object (so that no other thread may modify it) you have to use the
lock.
I think t's worth mentioning in the tutorial.
Another thing that I'd like to see added in the update section is about
long transactions. A lot of users are using the odmg API in web
applications, where business objects are modified in the GUI and then
persisted by a DAO. So Objects are not modified within a transaction.
This is really FAQ and I'd be happy if it'd be answered in the tutorial!
to make sure that OJB can still persist the changes made outside the
transaction we need the following code:
public static void persistChanges(Product product)
{
Implementation impl = OJB.getInstance();
TransactionExt tx = (TransactionExt) impl.newTransaction();
tx.markDirty(product);
tx.commit();
}
where TransactionExt is an OJB specific extension to the ODMG
Transaction interface that contains helper methods to obtain the
underlying PB or to mark objects for DELETE or UPDATE.
thanks,
Thomas
>
> Etc.
>
> As it is only in CVS, I have a copy up at
> http://kasparov.skife.org/ojb/odmg-tutorial.html
>
> Thanks,
> Brian
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
> For additional commands, e-mail: ojb-dev-help@db.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org