Ayende @ Rahien

Paul Hiles commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Sat, 16 Jul 2011 06:29:25 GMT

For anyone still struggling to see why (1) it is bad practice to call Resolve from anywhere but the root of your application and (2) abstracting your IoC container is generally unnecessary, this article (series) might help: http://www.devtrends.co.uk/blog/how-not-to-do-dependency-injection-the-static-or-singleton-container

flukus commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Fri, 08 Jul 2011 09:36:03 GMT

I'd find this funny if I didn't have to spend 6 months of my life working on a code base much like it. I don't follow the law of demeter very closely but all those resolve calls seem to be a pretty clear violation. I also don't understand abstracting the container. One of the things about IOC that always amazed me was how such a fundamental part of an application can be completely replaced in a matter of hours.

Abed commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Thu, 07 Jul 2011 11:16:47 GMT

Then you got a point, i thought you are posting about the new version. keep up the good job of reviewing this guidance ... anyway it is a good step already that microsoft officially trys to support DDD style application instead of their traditional data oriented anemic MS-TLSA style applications.

Ayende Rahien commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Thu, 07 Jul 2011 10:40:14 GMT

Abed, I am not posting about the pre-release version, I am posting about the actual release, Official Guidance version, which contains all of those problems.

Abed commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Thu, 07 Jul 2011 10:38:06 GMT

Note that this application (specially V2) is still in draft phase, and if you see the frequency of refactoring and changes you will notice that it is still far from being complete. Even the point we are discussing about the IoC used as service locator from WCF remote facade, they changed it already a couple of days ago, added IInstanceProvider in WCF for injecting dependencies and removed IoC project. So I guess we can delay full judgement till the release. Still it is very beneficial to discuss the aspect while it is still in development phase but without much expectation of finished work.

Ayende Rahien commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Thu, 07 Jul 2011 10:33:53 GMT

Per, I like that it is in the blog

Per Erik Stendahl commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Thu, 07 Jul 2011 10:32:22 GMT

Wow, 12 lines of error handling infrastructure for 2 lines of application logic. Very nice discussion though. Ayende, here's a suggestion for you: make a wiki for these posts so people can post their own code suggestions and discuss it!

Hendry Luk commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Thu, 07 Jul 2011 03:40:15 GMT

I'm completely with you Ayende. It's rather worrying when you see code like this end up in an official design guidline. It's extremely hard to imagine this is an official guideline produced by the same organisation who wrote asp.net MVC, MEF, Prism Rx, etc. It just shows an apparent fracture in the believe-systems among different teams at Microsoft.

Hendry Luk commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Thu, 07 Jul 2011 03:19:27 GMT

@Kash. You don't abstract IoC container. You might want to abstract service-locator, but no you don't abstract IoC container. To swap the container with other technology, you can just do that right away without the need for any abstraction, due to the very nature of IoC pattern.

steve commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Wed, 06 Jul 2011 09:57:59 GMT

Adrian: "Oh really? And have you ever asked your fellow developers what they think when one of your Resolve calls blows up in production because...oh...you didn't know about it and didn't register the implementation? Solid! " LOL ! Dude thats my point ! Imagine how much more difficult that would be to debug if it was being set up in application configuration using property based injecttion. Yeah real solid ! Besides that doesnt happen becuase you test your application before you deploy. You do test your applicaiton before you deploy dont you? oops !. Using complicated Ioc techniques negates the whole point of Ioc in the first place: To simplify the development process !

Tudor commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Wed, 06 Jul 2011 07:13:38 GMT

@steve "Tudor, too many dependencies is not a reason to use resolve rather than constructor based injection. That is also unacceptable, the class should instead be refactored to smaller classes!" ---- I agree with you - I just described a reality, did not say that it's good to do that way.. The path to SOLID principles, 'clean code' and refactoring is a long and difficult one for many developers, so in a less than ideal world many compromises should be done, unfortunately (f course, this is not an excuse for a guidance such as this).. I've worked this year with architects from Microsoft, in a project, and some of them still don't make the difference between proper unit testing and integration tests, think that the proper way to implement a logger class is with static classes and don't even consider using DI or IoC in a project..

Ayende Rahien commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Wed, 06 Jul 2011 05:30:22 GMT

Jay, You mean, like the thousands of posts on this blog? My IoC category alone contains dozens of them.

Chuck commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Wed, 06 Jul 2011 00:55:15 GMT

These post by Ayende often frustrate me because they can challenge my status quo! I've abstracted my container just to demonstrate that I can change it, but, for a day to day application, I change containers about as often as I change my database - it just doesn't happen as much as I want to think it will.

Jay commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 22:01:07 GMT

I've noticed with several of Ayende's articles, that he seems to be writing to an audience that already understands what he is saying and agrees with him. This is not useful to the novice that may want to learn from him and avoid the mistakes he seems to be pointing out. Comments such as " it is pretty clear that you don’t really get what IoC is all about" should be backed up with some sort of justification or at least a link to an article that explains what the problem is. Same thing with why it is a bad idea to litter your code with Factory calls. Why is this bad? What is better?

Adrian commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 21:00:39 GMT

"Guys my decisions with regard to things like this are driven by S.O.L.I.D and Clean principles. I think we sometimes forget that we are part of a team and as a result do not consider fellow developers" Oh really? And have you ever asked your fellow developers what they think when one of your Resolve calls blows up in production because...oh...you didn't know about it and didn't register the implementation? Solid!

steve commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 10:13:22 GMT

Ayende, Just for the record I still think your awesome ! But I do enjoy a technical debate !

steve commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 10:08:33 GMT

Tudor, too many dependencies is not a reason to use resolve rather than constructor based injection. That is also unacceptable, the class should instead be refactored to smaller classes! Guys my decisions with regard to things like this are driven by S.O.L.I.D and Clean principles. I think we sometimes forget that we are part of a team and as a result do not consider fellow developers. Often as a consultant coming into a project, it's too easy to just do whatever to get the job done (property injection) because you know you won't be around to debug it when it goes wrong ! I think part of being a good developer is less about writing complex code but about writing code that reads like a book to other developers, code that is maintanable and easy to change and code that is 'elegant'.

steve commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 09:58:04 GMT

Ayende, I think we will have to agree to disagree on that. Using resolve still uses the container I don't see the difference. Property injection breaks encapsulation, is harder to understand and results in spaghetti code. I would rather have a property who's Get method calls resolve (on an abstraction) for readability than have public properties all over the place. But let me re iterate; Using Resolve should be avoided for all the reasons people have mentioned but when in the situation where you can't avoid it then I don't think property injection is an acceptable answer.

Tudor commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 09:40:07 GMT

Another reason why many people use a service locator and access the container directly to resolve dependencies is that they create very coupled classes with many dependencies - so instead of having one constructor with 40 arguments some think it's more 'elegant' to spread the Resolve<> class in various methods.. :)

Ayende Rahien commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 08:22:36 GMT

Steve, Property Injection means that you still have the container manage the dependencies. It actually uses the container. Using Resolve all over the place means that you have broken that, making a lot of the features of the container useless.

steve commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 06:43:06 GMT

VladB: By using an IoC container you are using the factory pattern ! That's the whole point ! I am not going to create yet another factory ! Ayende: Property injection breaks encapsulation. Interesting that you would sacrifice good OO code for some idealism of not calling Resolve on your container directly. Guys I agree with the resolve point in principle, but like i keep saying; calling resolve is a last resort and for me property injection is the very last thing i would do !

VladB commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 04:32:15 GMT

@Steve: When you have to resolve a dependency in the very last minute you should use factory pattern, not IoC-container itself. IoC-container is intended to be used in only one place to build object graph and resolve dependecies. You are about to get rid of IoC-container after that.

Johan commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 02:33:10 GMT

Lest anyone thing I'm being a bit harsh... I made exactly these same mistakes the first time I used IoC, and over time I learned from these mistakes :)

Johan commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 02:31:35 GMT

Rob Ashton has it exactly right. When I see .Resolve() calls, I immediately know I am dealing with someone who just found out about IoC, and hasn't yet discovered how much simpler constructor or property injection makes your code. How is passing the container around to every method and calling Resolve() any different to singleton GetInstance() sprinkled through the application. If you use a non-crap IoC container like StructureMap or Autofac, constructor & property injection Just Works. Then, you have a "hard dependency" on your container only in the bootstrap code which is usually one method, and not in 50 million places in your code base. Then, you don't need to abstract the f***ing thing. And your tests are simple because you're only mocking the ACTUAL dependencies not the whole f****ing container. :)

David commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Tue, 05 Jul 2011 00:14:28 GMT

Microsoft + Guidance = Oxymoron

tobi commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Mon, 04 Jul 2011 22:06:26 GMT

Omg what an abomination! Look at the spelling the the comments of the NullRef handler. This code was written in India. I just noticed that, in addition to being in the wrong place, the code in the two catch clauses is the same. I cannot believe this. What a disgrace!

Ayende Rahien commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Mon, 04 Jul 2011 17:41:05 GMT

Kall, I can't recall of it off hand, but I think you can make it do so by playing with: PropertiesDependenciesModelInspector

SteveR commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Mon, 04 Jul 2011 17:39:53 GMT

@KallDrexx: I'll reply on your blog rather than leech Ayende's bandwidth. ;)

KallDrexx commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Mon, 04 Jul 2011 17:38:20 GMT

@Ayende, I just figured out what you meant by property injection. I honestly didn't know that was possible. That makes life so much easier, and is a much better solution. I just need to find a way to mark the properties so that Windsor will error if it can't resolve them.

KallDrexx commented on Review: Microsoft N Layer App Sample, Part IV-IoC FTW

Mon, 04 Jul 2011 17:29:42 GMT

@SteveR: I like the idea from that article of separating out 1 controller per action, that seems like an interesting idea (although that will require a lot of routing code to make sure I don't break existing links in my application). However, I don't like the way he uses his models to perform the business logic as it seems to require the controllers themselves to perform the data access. Instead I prefer my service classes to perform all the calls to the data layer, as that also makes it easier to contain all my business and data logic outside of the MVC architecture. It also means I don't have to rewrite my data access calls if I extend my application out to a WCF or Silverlight basis. Unless I am misreading that post at least.