Comments on: How to implement unit-testable abstraction and reusable domain models with IoC + ORM? http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/ Moving towards the efficient development of smart software solutions in C# .NET Mon, 08 Sep 2008 07:02:32 +0000 http://wordpress.org/?v=2.6.1 By: Rinat Abdullin http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-435 Rinat Abdullin Tue, 11 Mar 2008 12:25:23 +0000 http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-435 Jeremy, thank you for your comprehensive comments. Yes, moving the Resolve calls back to the super-type (along with making it protected) seems logical. Free DI-related methods with unbound service location could be really dangerous in big development teams. And if somebody ever needs to deliver a domain object library, that is easy to extend, they can just make the Resolve public. About the performance. Personally I'm not sure yet if using some complex logic for field initializers is worth it in the long run. That will be some repetitive code out there. If it were possible to create some dictionary-type quick adapter on this Resolver interface (to cache singleton and container-scoped instances) then the performance could be appropriate for the majority of UI-related usage scenarios. However, I personally haven't even profiled autofac itself. Surviving across container scopes seems a little bit tricky for me now. In series usage scenarios (and in my projects) session always has the life cycle of the container it is in. And so are the BOs that were created with it. There could be child containers below (using the same session or UoW override, and/or BO instances from the upper container). But when this container dies, then logically everything else within it should be already on its way to the GC. Jeremy, please, keep me updated of your findings, if you do not mind! BTW, do you have weblog? Best regards, Rinat Jeremy,

thank you for your comprehensive comments.

Yes, moving the Resolve calls back to the super-type (along with making it protected) seems logical. Free DI-related methods with unbound service location could be really dangerous in big development teams.

And if somebody ever needs to deliver a domain object library, that is easy to extend, they can just make the Resolve public.

About the performance. Personally I’m not sure yet if using some complex logic for field initializers is worth it in the long run. That will be some repetitive code out there.

If it were possible to create some dictionary-type quick adapter on this Resolver interface (to cache singleton and container-scoped instances) then the performance could be appropriate for the majority of UI-related usage scenarios. However, I personally haven’t even profiled autofac itself.

Surviving across container scopes seems a little bit tricky for me now. In series usage scenarios (and in my projects) session always has the life cycle of the container it is in. And so are the BOs that were created with it. There could be child containers below (using the same session or UoW override, and/or BO instances from the upper container). But when this container dies, then logically everything else within it should be already on its way to the GC.

Jeremy, please, keep me updated of your findings, if you do not mind!
BTW, do you have weblog?

Best regards,
Rinat

]]> By: Jeremy Gray http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-430 Jeremy Gray Mon, 10 Mar 2008 21:33:28 +0000 http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-430 PPS - Just pretend that the Resolve calls have a type specifier on them, as it got eaten each time by the comment engine. PPS - Just pretend that the Resolve calls have a type specifier on them, as it got eaten each time by the comment engine.

]]> By: Jeremy Gray http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-429 Jeremy Gray Mon, 10 Mar 2008 21:32:22 +0000 http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-429 PS - This will probably be done as simply as by declaring a nice little "protected T Resolve()" method in my domain layer supertype and invoking it in my field initializers, as they'll each only be invoked upon first usage of each field. If any domain objects need to survive across container scopes, they can avoid using the fields and (at the cost of a bit more typing) do per-usage Resolve() calls any time they need access to a service. PS - This will probably be done as simply as by declaring a nice little “protected T Resolve()” method in my domain layer supertype and invoking it in my field initializers, as they’ll each only be invoked upon first usage of each field. If any domain objects need to survive across container scopes, they can avoid using the fields and (at the cost of a bit more typing) do per-usage Resolve() calls any time they need access to a service.

]]> By: Jeremy Gray http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-428 Jeremy Gray Mon, 10 Mar 2008 21:27:16 +0000 http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-428 Just to summarize your post modulo XPO specifics, here is what I'm gathering: Relative to the issues from earlier in the series, you've chosen to use a service locator (exposed via a layer supertype) for IoC within your domain, and continue to use use DI for IoC within your services. This is a pretty common approach (historically the most common), getting us most of the way there, with the only main set of trade-offs being that your domain objects will have to make Resolve calls in order to avoid hooking into your ORMs domain object instantiation code (and forcing other code to instantiate through factories) and then suffering the overhead of injecting services into thousands/millions/billions/etc. of domain object instances that may not even end up needing their services. The more I've thought about this over the last several days, the more I'm starting to think that the perf overhead of the more quote/unquote "elegant" approach using 100% DI may be worth avoiding at the cost of having to make Resolve calls. With that in mind I'll probably focus my efforts on cooking up nice, lean, (deferred!) field initializers so that at the very least the Resolve calls can be nicely centralized at the point where each service instance field is declared in each domain class. Just to summarize your post modulo XPO specifics, here is what I’m gathering: Relative to the issues from earlier in the series, you’ve chosen to use a service locator (exposed via a layer supertype) for IoC within your domain, and continue to use use DI for IoC within your services.

This is a pretty common approach (historically the most common), getting us most of the way there, with the only main set of trade-offs being that your domain objects will have to make Resolve calls in order to avoid hooking into your ORMs domain object instantiation code (and forcing other code to instantiate through factories) and then suffering the overhead of injecting services into thousands/millions/billions/etc. of domain object instances that may not even end up needing their services.

The more I’ve thought about this over the last several days, the more I’m starting to think that the perf overhead of the more quote/unquote “elegant” approach using 100% DI may be worth avoiding at the cost of having to make Resolve calls. With that in mind I’ll probably focus my efforts on cooking up nice, lean, (deferred!) field initializers so that at the very least the Resolve calls can be nicely centralized at the point where each service instance field is declared in each domain class.

]]> By: Rinat Abdullin http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-425 Rinat Abdullin Mon, 10 Mar 2008 05:38:42 +0000 http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-425 Alex, you are welcome. Best regards, Rinat Alex,

you are welcome.

Best regards,
Rinat

]]> By: Alex Hoffman http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-424 Alex Hoffman Sun, 09 Mar 2008 21:03:43 +0000 http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-424 Rinat, many thanks for that. -- Alex Rinat, many thanks for that.

– Alex

]]> By: Rinat Abdullin http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-423 Rinat Abdullin Sun, 09 Mar 2008 11:06:52 +0000 http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-423 Alex, Sure. Please, take a look at the next post. Additionally, I've posted a question about DXperience code sharing here: http://community.devexpress.com//forums/p/62768/212865.aspx#212865 Best regards, Rinat Alex,

Sure. Please, take a look at the next post.

Additionally, I’ve posted a question about DXperience code sharing here:
http://community.devexpress.com//forums/p/62768/212865.aspx#212865

Best regards,
Rinat

]]> By: Alex Hoffman http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-420 Alex Hoffman Sun, 09 Mar 2008 00:44:54 +0000 http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-420 Many thanks, I've found the series culminating in this post really thought provoking. One thing. You mention... "Additionally we register the interface in slightly patched version of XPO’s ReflectionDictionary just to make it recognize the BO when it is asked to load its interface." Is it possible to see the modified ReflectionDictionary code? -- Alex Many thanks, I’ve found the series culminating in this post really thought provoking.

One thing. You mention… “Additionally we register the interface in slightly patched version of XPO’s ReflectionDictionary just to make it recognize the BO when it is asked to load its interface.”

Is it possible to see the modified ReflectionDictionary code?

– Alex

]]> By: How to use ORM (XPO), IoC, C# 3.5 syntax, Linq and .NET 2.0 together? at Rinat Abdullin http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-419 How to use ORM (XPO), IoC, C# 3.5 syntax, Linq and .NET 2.0 together? at Rinat Abdullin Sat, 08 Mar 2008 12:46:41 +0000 http://rabdullin.com/how-to-implement-unit-testable-abstraction-and-reusable-domain-models-with-ioc-orm/#comment-419 [...] the ability to work with the actual object without any type casting)… you can check out the next post for [...] [...] the ability to work with the actual object without any type casting)… you can check out the next post for [...]

]]>