Hi Nathan,
first of all, happy new year!!! That's very interesting and I'd like
to contribute!!!
A friend of mine and I have been developing a google-guice/ibatis3
bridge (including dao) with 3rd part datasources (c3p0 and Commons
DBCP) and caches (OSCache, Ehcache, Memcached and JBoss-Cache)
integ
Hi,
does my configuration looks incorrect somewhere
Clinton Begin wrote:
>
> Well... I don't know what to tell you. iBATIS isn't reporting an error,
> and
> doesn't often fail silently (if ever). You can try turning on logging and
> replace your main method with a unit test that has assertio
Thanks for the replies its working now .
Clinton Begin wrote:
>
> Well... I don't know what to tell you. iBATIS isn't reporting an error,
> and
> doesn't often fail silently (if ever). You can try turning on logging and
> replace your main method with a unit test that has assertions like
> ass
Clinton Begin wrote:
>
> Dan,
>
> Why should your domain layer bend to the whims of the persistence
> layer? Because you also chose the persistence layer. Frameworks are
> inherently composed of many assumptions and constraints. Despite your
> assertions, the design you propose is atypical.
>
Dan,
In short I think the largest issue I have seen with your thought process is
over design issues. You reference that you want to use Guice but the Guice
team would disagree with your approach to use static factory methods instead
of constructors. DI frameworks like Guice have almost removed a
Perhaps an alternative to individual classes for each data type would
be to use the builder pattern? That would avoid having many, many
parameters on the constructor for the User class. This might help
with the problem of figuring out whether arguments at the call site
match the formal parameters
nmaves wrote:
>
> Dan,
>
> In short I think the largest issue I have seen with your thought process
> is
> over design issues. You reference that you want to use Guice but the
> Guice
> team would disagree with your approach to use static factory methods
> instead
> of constructors. DI framew
Martin Ellis-6 wrote:
>
> Perhaps an alternative to individual classes for each data type would
> be to use the builder pattern? That would avoid having many, many
> parameters on the constructor for the User class. This might help
> with the problem of figuring out whether arguments at the ca
I'm not aware of any O/R mapper that would elegantly handle a micro-typed
domain. Since frameworks are largely built for commodity application of
common practices, I'm not sure one will be easily found. This is a unique
design practice, and thus will require a unique solution.
Clinton
On Mon, J
