Well, not so unique design practice now, i think.
I'm trying now to implement solution based on scala & iBatis and want to use
scala's case classes for domain model. But common way to initialize such
objects is parametrizing through constructor.
so, i have (for example) such definitions:
trait B
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
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
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
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
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
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,
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.
I'm going to be totally honest with yo
Guy Rouillier-2 wrote:
>
> Comments inline. Overall, you seem to have made this much more
> complicated than it needs to be. Looking at your database schema from
> your original message, all the table columns are simple strings or
> number, except for the gender enum. But you've elected to
Comments inline. Overall, you seem to have made this much more
complicated than it needs to be. Looking at your database schema from
your original message, all the table columns are simple strings or
number, except for the gender enum. But you've elected to make every
column a distinct objec
Thank you, Guy, you have been a big help!
This is what I came up with. It works, but not as well as I had hoped.
On 12/30/2009 1:39 PM, Dan Forward wrote:
The Association tag looks promising, but I am confused by the column
attribute. It wants an ID for the Name, but Names are not first-class data
objects and have no ID. The Association tag seems to be intended for a
one-to-many or many-to-many join. I cou
Guy Rouillier-2 wrote:
>
>
> You don't say what version of iBATIS you are using. Since you say you
> are new, so I'm guessing you are using iBATIS 3. You shouldn't need any
> callbacks; from your description, a simple ResultMap should suffice.
> Take a look at the iBATIS 3 User Guide, part
On 12/29/2009 6:22 PM, Dan Forward wrote:
I am new to iBATIS and I am having difficulty mapping our User object, which
consists of several custom objects, some of which span multiple columns in
the database. However, all the data for the user is stored in one table.
These are the properties of
14 matches
Mail list logo
