Ayende @ Rahien

Ayende Rahien commented on Infrastructure Ignorance

Thu, 14 Feb 2008 16:40:05 GMT

PowerPoint 2007

Ken Sykora commented on Infrastructure Ignorance

Thu, 14 Feb 2008 16:20:13 GMT

Just out of curiosity, what do you use to generate those images? It looks very slick and I do presentations from time-to-time that I could use something like that for.

Bil Simser commented on Infrastructure Ignorance

Wed, 13 Feb 2008 16:04:23 GMT

To counter Frans' point Greg Young and co. were doing some additional steps post-build that would allow you to write this code: SomeType s = new SomeType(); // no stuff gets injected but get this result: SomeType s = Factory.Produce(); // stuff gets injected They went in and replaced the IL calls to new with whatever factory/container they wanted (all defined in configuration) so newbs could just keep writing "new this" and "new that" without worrying about all the extra stuff going on in the background. I don't agree you need to be aware of any container. In fact, I would rather have all my developers know nothing of containers and such (other than "we use them" and the principle behind them) and focus on writing good, strong domain code. Would be a good discussion to get Frans, Oren and others together to talk about this. Maybe soon... (DevTeach/ALT.NET/etc.)

Nigel Sampson commented on Infrastructure Ignorance

Wed, 13 Feb 2008 14:21:57 GMT

I think the difference between what Ayende and Frans are talking about is that even if you don't have any direct references to your IOC container throughout your code you still need to be aware that there is an container. The fact we have a IOC container means we code our services in a certain way (pushing dependencies to the ctor and not using new()). In summary, while we should strive for code that is ignorant of the container we still need to be aware that is is there and code appropriately.

Jeroen Weelink commented on Infrastructure Ignorance

Wed, 13 Feb 2008 12:07:14 GMT

Have you taken a look at the ports-and-adapter architecture (a.k.a Hexagonal architecture)? http://alistair.cockburn.us/index.php/Ports_and_adapters_architecture It seems it provides the exact thing you are searching for. I'm afraid I don't have a lot of experience with this yet, but it looks interesting.

Ayende Rahien commented on Infrastructure Ignorance

Wed, 13 Feb 2008 09:59:15 GMT

Let us take a MonoRail app as a good example. The infrastructure makes a call to the container to get the relevant controller. The controller is injected all its dependencies, and their dependencies, and _their_ dependencies, etc. At no point do I need to call the container for anything. In a smart client app, we need more control, because we need to handle the lifetime of objects explicitly. In this case, I'll have the ApplicationController have a method like ShowView(), which will call the container. That is what I am talking about when I am saying that you have a very small bridge between the domain services and the infrastructure. In this case, the app controller is that bridge. And the interaction is highly limited, on purpose.

Frans Bouma commented on Infrastructure Ignorance

Wed, 13 Feb 2008 09:48:07 GMT

I don't care if it is in production, there is a lot of bad code in production, that doesn't make it correct code. "And there is a single place where they hit the container, and that is very deep in the infrastructure code. Put simply, this is very bad code: SomeType s = Factory.Produce();." You missed my point. What I'm saying is that if I use 'new' in my code instead of calling some factory/repository or whatever you want to call it, I skip the infrastructure code and therefore don't benefit from its features. Which means I HAVE TO use a given way to create objects instead of the 'new' operator. This thus implies that by using the IoC principle and not having ctor-driven DI, you have to use other ways to create objects. I'm NOT saying that that is BAD, on the contrary. I'm just highlighting that by using OTHER ways to create objects than the 'new' operator, you have to follow the rules forced upon you by the infrastructure, the framework you're using. So saying that code should be written without ANY ties to the infrastructure used is in theory a great goal, however in practise undoable, as you will have code written and designed which strictly follows the rules dictated by the infrastructure. When I see someone creating an object using a call to some other object (you can declare my stupid example as bad code, but you do have to create your IoC using code somewhere, so you have to call out to whatever you use as infrastructure, be it wrapped in repositories or something else, you can't use 'new') instead of using 'new' I fail to see how that ISN'T using code which is dictated by the infrastructure used. Otherwise why not use 'new' as with any other class? "Have it injected by the container, and you don't have a dependecies on the container" How can I tell the container to do the DI for me if I can't call the container because that would be a dependency? Via a wrapper? Ok, though then I have an indirect dependency, and a direct dependency on the wrapper. You might think that the wrapper disconnects the two but you're mistaken: I can't continue with using 'new' instead of calling the wrapper/intermediate class/repository etc. Again: I'm NOT saying that using repositories/factories etc. is bad, on the contrary. I'm just saying that the necessity to use them to get infrastructure working, so you've to give up the freedom to use 'new', IS forced upon you by the infrastructure. Perfectly fine by me, though it clashes with the picture painted by you in your post that you should write code which is unaware of infrastructure. I find that impossible to do if I have to give up the freedom to use 'new' BECAUSE of that infrastructure usage! Like giving up that freedom 'doesn't count' in the concept of 'code unaware of infrastructure'.

Ayende Rahien commented on Infrastructure Ignorance

Wed, 13 Feb 2008 09:14:59 GMT

Frans, I am sorry, but you do realize that I am describing the reality on real projects. They just happen to be in production for over a year. And there is a single place where they hit the container, and that is very deep in the infrastructure code. Put simply, this is very bad code: SomeType s = Factory.Produce(); Have it injected by the container, and you don't have a dependecies on the container.

Frans Bouma commented on Infrastructure Ignorance

Wed, 13 Feb 2008 09:09:18 GMT

"The IoC container that you use shouldn't appear anywhere in your code, nor should the persistence concerns mix themselves with the actual code. Invasive approaches, no matter what they do, should be frowned on." haha good luck with that! See, if I want to use an IoC container, and I'm forced to use a factory to produce my objects so I get stuff injected, I _AM_ forced to work a given way BECAUSE of the infrastructure I use. So it's not called directly in your code, however it IS called indirectly in such a way that it is visible in your code: SomeType s = new SomeType(); // no stuff gets injected SomeType s = Factory.Produce(); // stuff gets injected In a world you describe in the quoted remark, I should be able to use the first statement AND get stuff injected WITHOUT worries. I also shouldn't worry about the fine-print details of the infrastructure used (i.e.: infrastructure code requires virtual properties/methods, infrastructure code injects code which manages graphs etc. etc.). Is that the world we're living in today? No, not at all. No matter what you do, you can't avoid infrastructure influence in your own code, not by a long shot. Remember: even if your code is influenced by just 1%, it has a connection with the infrastructure used so you can't do everything you wanted without consulting the infrastructure code's specs. It would be great IMHO if people in the blog-o-sphere start describing the reality instead of describing a dreamworld which isn't there. (oh of course, the aspects I describe are only popping up when someone is doing something wrong or not using the 'right' tools... I get it)

Ayende Rahien commented on Infrastructure Ignorance

Tue, 12 Feb 2008 21:59:45 GMT

Harry, I don't like the concept, it looks to me like they are trying to make DCOM all over again. Infrastructure Ignorance is all very nice, but out of process calls should never be hidden.

Ayende Rahien commented on Infrastructure Ignorance

Tue, 12 Feb 2008 21:59:44 GMT

Harry, I don't like the concept, it looks to me like they are trying to make DCOM all over again. Infrastructure Ignorance is all very nice, but out of process calls should never be hidden.

Harry M commented on Infrastructure Ignorance

Tue, 12 Feb 2008 21:56:59 GMT

What do you think of the Volta project? Its has lofty aims of stripping out just about anything that isn't application code and might be just the thing for improving infrastructure ignorance once its cooked.

Jeremy D. Miller commented on Infrastructure Ignorance

Tue, 12 Feb 2008 20:48:10 GMT

1.) Love the graphics and ditto 2.) Add a bit more venom on UI ignorance. IPropertyNotifyChanged/IEditableObject/INeedToAddUglyCrapToMyCodeToAppeaseTheDataBindingGods is pure code noise that has no place in anything resembling a Domain Model.