We had a debate - cons and pros of having a factory per dto in order to test some service. The idea is that the service is being invoked with primitive types parameters (username, password, etc), but the service dependency should be leveraged using those primitives. The only way to test it was to inject into service an additional dependency, DtoFactory, and that way to ensure that primitive parameters are utilized the way we wanted. What worries me is the idea of "FactoryX per DtoX". What would be an alternative? Thanks
A:
Doesn't .NET Tiers use this model? I guess you could read online some of the criticism of that framework.
Couldn't you write a Generic Factory?
tyndall
2009-01-29 04:49:29
Generic factory? Not sure how would you accomplish that when each dto has a different parameters list. Besides, it's too "smelly" IMO. We were doing the test in a wrong manner :)
Sean
2009-01-30 02:33:12
A:
Using the spring framework I would simply not be putting the login information into the DTO (or in Thread Storage that I manage) any more. I'd simply let spring inject the proper credentials into the service when needed.
This works really nice with login information. When running integration tests like you are doing, spring takes care of it all.
You asked for alternatives ;)
krosenvold
2009-01-29 06:21:52
A:
I think I answered my own question. Testing part should not drive that requirement. Test should be done in a different manner. Rhino Mocks 3.5 helps to accomplish that to eliminate any need in a factory per dto. I blogged about it here: http://weblogs.asp.net/sfeldman/archive/2009/01/29/factory-per-dto.aspx
Thanks for opinions/suggestions.
Sean
2009-01-30 02:31:46