OK, here an example:
A User is encapsulating password details. It gets a plain-text as input
is taking security actions internally. Because I want to extract
security implementation details (encryption/hashing) from the domain
model I want to end up with an injectable security instance. Still
things should be handled from the domain object.
class User{
...
//provides security actions on a string input, password should not be
kept as plaintext
@Inject PasswordEncoder
...
//one use case to have the password knowledge
public boolean isEligible(String password){...}
}
I know I could handle all this password stuff outside of the User (e.g.
AuthentcationService). This is also dependant how it technically fits to
a used security framework (authorize/authenticate). With this example I
just wanted to show that it can make sense to inject services to a
domain-object.
I hope you can see my motivation why I want to add a set of classes by
package name into SerivceBinder.bind(). E.g. autobuild all my
domain-object from a model package.
Christian Edward Gruber schrieb:
Oh, sorry - ServiceBinder... I was thinking you were injecting a
service lookup object into your model - I was clearly too brain-dead
and didn't read it properly.
So, you're binding services in modules and injecting them with @Inject
- that's fine, so far. But I don't understand, then, how you're
injecting things into value objects? That just doesn't make sense to
me. Can you provide a cleansed example?
Christian.
On 21-Apr-09, at 06:49 , manuel aldana wrote:
I don't see a problem here. I am having dependencies on interface
level which should be fine. For testability I can just inject a
test-implementation of this interface. I don't see a strong coupling
to the container in my model (apart from the @Inject annotation).
Christian Edward Gruber wrote:
Are your model classes their own controllers? If you're doing what
you describe, then you're tightly coupling your model classes to the
implementation of the application. It's not forbidden or anything,
but it's often not considered best practice (though as with all good
practice, there are notable exceptions, so I don't want to judge
hastily). But I typically consider this a DI/IoC anti-pattern -
injecting the container itself or statically binding the container
(via ServiceBinder) into domain objects. Makes things hard to test,
hard to disentangle, and really really hard to port later.
Christian.
On 20-Apr-09, at 15:42 , manuel aldana wrote:
Hi,
I am injecting services to my domain model classes. For that I am
using the ServiceBinder.bind(implementationClass). This is kind of
repetitive if I want to add all classes of a certain package.
Is it somehow possible to add a set of class at once to autobuild
control, for instance by passing a package identifier?
--
manuel aldana
ald...@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Christian Edward Gruber
e-mail: christianedwardgru...@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Christian Edward Gruber
e-mail: christianedwardgru...@gmail.com
weblog: http://www.geekinasuit.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
manuel aldana
ald...@gmx.de
software-engineering blog: http://www.aldana-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
