You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Edgar Merino <do...@gmail.com> on 2008/10/16 03:00:08 UTC
Domain Model as interfaces
Hello,
I couldn't find any other place to post this, so I'm doing it here,
(it's related to java web development anyway). I've been working on a
project where wicket has access to the domain layer through interfaces
because I didn't want my project to depend on any dbms, however I've
been thinking and the main problem here lies with db4o, since it cannot
make use of JPA annotations on entities (domain models). I would like to
get rid of those interfaces and use concrete implementations to handle
business code inside the entities, but then the above problem arises. So
what recommendations can you give to have a fully implemented domain
model (using jpa annotations) but still be able to use any dbms (or
orm/dmbs) without having to map those the domain model at the service
layer? I hope I can get some feedback on this, as it has been the main
problem I've been facing when coding scalable web applications.
Regards,
Edgar Merino
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Domain Model as interfaces
Posted by James Carman <ja...@carmanconsulting.com>.
By the way, I just added a DB4O implementation to Domdrides. The only
catch is that you have to download DB4O yourself and install into your
local maven repository to get the build to work. Good luck! Hope
that helps.
On Thu, Oct 16, 2008 at 6:27 AM, James Carman
<ja...@carmanconsulting.com> wrote:
> Are you using interfaces for your entities or your repositories
> (DAOs)? If you'd like a library to start from, check out Domdrides (a
> DOMain-DRIven DESign library):
>
> http://domdrides.sourceforge.net
>
> Basically, it provides a common API for doing domain-driven design and
> also provides some useful superclasses for doing repositories using
> different ORM implementations (currently Hibernate, JPA, and iBATIS,
> but a DB4O implementation would be welcomed).
>
> On Wed, Oct 15, 2008 at 9:00 PM, Edgar Merino <do...@gmail.com> wrote:
>> Hello,
>>
>> I couldn't find any other place to post this, so I'm doing it here, (it's
>> related to java web development anyway). I've been working on a project
>> where wicket has access to the domain layer through interfaces because I
>> didn't want my project to depend on any dbms, however I've been thinking and
>> the main problem here lies with db4o, since it cannot make use of JPA
>> annotations on entities (domain models). I would like to get rid of those
>> interfaces and use concrete implementations to handle business code inside
>> the entities, but then the above problem arises. So what recommendations can
>> you give to have a fully implemented domain model (using jpa annotations)
>> but still be able to use any dbms (or orm/dmbs) without having to map those
>> the domain model at the service layer? I hope I can get some feedback on
>> this, as it has been the main problem I've been facing when coding scalable
>> web applications.
>>
>> Regards,
>> Edgar Merino
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Domain Model as interfaces
Posted by James Carman <ja...@carmanconsulting.com>.
Are you using interfaces for your entities or your repositories
(DAOs)? If you'd like a library to start from, check out Domdrides (a
DOMain-DRIven DESign library):
http://domdrides.sourceforge.net
Basically, it provides a common API for doing domain-driven design and
also provides some useful superclasses for doing repositories using
different ORM implementations (currently Hibernate, JPA, and iBATIS,
but a DB4O implementation would be welcomed).
On Wed, Oct 15, 2008 at 9:00 PM, Edgar Merino <do...@gmail.com> wrote:
> Hello,
>
> I couldn't find any other place to post this, so I'm doing it here, (it's
> related to java web development anyway). I've been working on a project
> where wicket has access to the domain layer through interfaces because I
> didn't want my project to depend on any dbms, however I've been thinking and
> the main problem here lies with db4o, since it cannot make use of JPA
> annotations on entities (domain models). I would like to get rid of those
> interfaces and use concrete implementations to handle business code inside
> the entities, but then the above problem arises. So what recommendations can
> you give to have a fully implemented domain model (using jpa annotations)
> but still be able to use any dbms (or orm/dmbs) without having to map those
> the domain model at the service layer? I hope I can get some feedback on
> this, as it has been the main problem I've been facing when coding scalable
> web applications.
>
> Regards,
> Edgar Merino
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Domain Model as interfaces
Posted by Edgar Merino <do...@gmail.com>.
hello daniel,
well yeah, maybe that can work, but still I'll have to override
every method in the base class in order to add annotations:
...
@Id
@GeneratedStrategy(..)
public Integer getId() {
return super.getId();
}
...
same thing for every getter/setter methods of the entity. I would
like to be able to switch easily between persistence providers because
right now I'm using hibernate but would like to change the provider to
db4o when I've got the time to do so, also this is a project I intend to
release so anyone can add the persistence provider they need easily.
Regards,
Edgar Merino
Daniel Frisk escribió:
> Hi,
>
> I'm not sure I understand exactly what is your problem but wouldn't
> something like this:
>
> Db4oImpl / JpaImpl / WhateverImpl ---extends--->
> AbstractBaseClassWithYourBusinessLogic ---implements---> YourInterface
>
> Where needed you would delegate to the base class (just adding the
> impl specific annotation). Just out of interest: do you really need to
> be able to easily switch between different persistence providers?
>
> // Daniel
> jalbum.net
>
>
> On 2008-10-16, at 03:00, Edgar Merino wrote:
>
>> Hello,
>>
>> I couldn't find any other place to post this, so I'm doing it here,
>> (it's related to java web development anyway). I've been working on a
>> project where wicket has access to the domain layer through
>> interfaces because I didn't want my project to depend on any dbms,
>> however I've been thinking and the main problem here lies with db4o,
>> since it cannot make use of JPA annotations on entities (domain
>> models). I would like to get rid of those interfaces and use concrete
>> implementations to handle business code inside the entities, but then
>> the above problem arises. So what recommendations can you give to
>> have a fully implemented domain model (using jpa annotations) but
>> still be able to use any dbms (or orm/dmbs) without having to map
>> those the domain model at the service layer? I hope I can get some
>> feedback on this, as it has been the main problem I've been facing
>> when coding scalable web applications.
>>
>> Regards,
>> Edgar Merino
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Domain Model as interfaces
Posted by Daniel Frisk <da...@jalbum.net>.
Hi,
I'm not sure I understand exactly what is your problem but wouldn't
something like this:
Db4oImpl / JpaImpl / WhateverImpl ---extends--->
AbstractBaseClassWithYourBusinessLogic ---implements---> YourInterface
Where needed you would delegate to the base class (just adding the
impl specific annotation). Just out of interest: do you really need to
be able to easily switch between different persistence providers?
// Daniel
jalbum.net
On 2008-10-16, at 03:00, Edgar Merino wrote:
> Hello,
>
> I couldn't find any other place to post this, so I'm doing it
> here, (it's related to java web development anyway). I've been
> working on a project where wicket has access to the domain layer
> through interfaces because I didn't want my project to depend on any
> dbms, however I've been thinking and the main problem here lies with
> db4o, since it cannot make use of JPA annotations on entities
> (domain models). I would like to get rid of those interfaces and use
> concrete implementations to handle business code inside the
> entities, but then the above problem arises. So what recommendations
> can you give to have a fully implemented domain model (using jpa
> annotations) but still be able to use any dbms (or orm/dmbs) without
> having to map those the domain model at the service layer? I hope I
> can get some feedback on this, as it has been the main problem I've
> been facing when coding scalable web applications.
>
> Regards,
> Edgar Merino
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org