Ayende @ Rahien

Ayende Rahien commented on Reviewing Unity

Thu, 28 Feb 2008 23:35:38 GMT

Alex, Okay, so I think that the docs are point to the wrong direction, but that remove a lot of the objections to it.

Alex Simkin commented on Reviewing Unity

Thu, 28 Feb 2008 23:32:23 GMT

BTW: Autofac automatically chooses the constructor with the most parameters that are able to be obtained from the container. (I think Windsor does the same).

Ayende Rahien commented on Reviewing Unity

Thu, 28 Feb 2008 23:31:12 GMT

Alex, For the first version, if I now add a new parameter to the ctor, I have a breaking change. For the second one, how does it figure out what parameters it should use?

Alex Simkin commented on Reviewing Unity

Thu, 28 Feb 2008 23:25:25 GMT

You can specify constructor to use. builder.Register().UsingConstructor(typeof(int)); Otherwise you can use Autowiring to cut down on repetitive configuration. var builder = new ContainerBuilder(); var controllerTypes = from type in Assembly.Load("MyWebApp").GetTypes() where typeof(IController).IsAssignableFrom(type) select type; foreach (var controllerType in controllerTypes) builder.Register(controllerType) .WithScope(InstanceScope.Factory); This doesn't preclude you from subsequently overriding one of these registrations to meet special requirements or improve performance: builder.Register(c => new HomeController(Settings.SiteName)) .WithScope(InstanceScope.Factory);

Ayende Rahien commented on Reviewing Unity

Thu, 28 Feb 2008 23:20:12 GMT

I means that it doesn't figure out, on its own, how to build things. This means that changing a ctor is a breaking change, for example.

Alex Simkin commented on Reviewing Unity

Thu, 28 Feb 2008 23:14:13 GMT

> You have to specify all the components by hand. You mean it doesn't have configuration engine in Boo ;-) ?

Ayende Rahien commented on Reviewing Unity

Thu, 28 Feb 2008 23:06:11 GMT

You have to specify all the components by hand. I am talking here about the impression I got from the first page, by the way. Having to go and specify how to build each type is not a workable solution in any system. I don't want to do that, that is the container's job.

Alex Simkin commented on Reviewing Unity

Thu, 28 Feb 2008 23:02:56 GMT

>This is not a really scalable approach Because?

Ayende Rahien commented on Reviewing Unity

Thu, 28 Feb 2008 23:01:33 GMT

This is not a really scalable approach

Alex Simkin commented on Reviewing Unity

Thu, 28 Feb 2008 22:57:16 GMT

What are your thoughts about Autofac IoC Container? http://code.google.com/p/autofac/

Ayende Rahien commented on Reviewing Unity

Mon, 25 Feb 2008 14:44:48 GMT

Have you seen how I do this kind of thing? I am generally working with Binsor, by defining rules for gathering the proper components. You can do it manually, via code, if you want. But it is generally a major PITA.

Derek Greer commented on Reviewing Unity

Mon, 25 Feb 2008 13:33:44 GMT

My project doesn't allow there to be a central configuration file, so any alternate product I would evaluate would have to be capable of being configured through code.

Ayende Rahien commented on Reviewing Unity

Mon, 25 Feb 2008 03:14:10 GMT

Don't assume, the config was a nightmare. At least half of that was the client's fault.

Derek Greer commented on Reviewing Unity

Mon, 25 Feb 2008 02:52:17 GMT

I assume you had the ability to manage a central config file to define all the mappings? Derek

Ayende Rahien commented on Reviewing Unity

Mon, 25 Feb 2008 01:31:47 GMT

Derek, I enjoy my blog, and the discussions in it. That is my motivation here. I also have the blog setup so I basically need to do very little to have this conversatin. Doing this on the Unity forums is work. As for my scenario, SaaS app, ~10 modules times 700 clients, each wanting their own tiny change. Oh yeah, it was composable all right.

Derek Greer commented on Reviewing Unity

Mon, 25 Feb 2008 01:17:46 GMT

I'm not sure your application had the same needs and restrictions as my own, but I appreciate your opinion nonetheless. As far as you caring about Unity's success, I certainly have made no assumptions in this regard. I only intended to suggest that in light of your experience in this area it would be valuable to share your critiques with the Unity development team. It certainly wouldn't be more work than debating with a nobody within the comments of one of your blogs :) Derek

Ayende Rahien commented on Reviewing Unity

Mon, 25 Feb 2008 00:06:46 GMT

Chris, Start a mailing list, that would make participating in Unity far less onerous. Right now, having to go to a forum site and track that is not a sustainable approach.

Ayende Rahien commented on Reviewing Unity

Mon, 25 Feb 2008 00:04:29 GMT

Derek, I _wrote_ a big application using Object Builder as the container. It was built in the classic MSDN style architecture. I have learnt a lot of things from that project, but most of them were what not to do. How do you think I could pull such a large list? I know all the soft spots of all IoC, I was there, I ate the pudding and I was sick in the bathroom afterward. I didn't get a TShirt for that, though, I wasn't implementing IShirtable. Another mistake is that I care about Unity in any deep way. This review was sparked by curiousity about Unity, not much more. I am juggling enough things, I believe. Taking an active part in another project is not realy feasiable.

Chris Tavares commented on Reviewing Unity

Mon, 25 Feb 2008 00:02:52 GMT

Ah, I misunderstood what Startable does. The Windsor documentation doesn't say anything about the semantics, so I assumed it was similar to our existing IBuilderAware interface, which it isn't. If I understand what it does now (automatically create an instance and call Start when enough dependencies are registered) then no, by itself Unity won't do it. I can think of a couple of ways to accomplish this, but I'll have to prototype it a bit first. Again, I ask everyone commenting on Unity here or on the altdotnet mailing list to come over to our codeplex site. We only find stuff here by accident, but are actively monitoring the project site. -Chris http://www.codeplex.com/unity

Derek Greer commented on Reviewing Unity

Sun, 24 Feb 2008 23:45:27 GMT

Ayende, I agree, learning new approaches is beneficial. Unfortunately, it sometimes takes actually writing a real application with a product and maintaining it for awhile to know how the differences in approach actually work out. I can imagine what it might be like to have to configure every single thing I want to use in my mega-composite application, but I may have to actually do it for a while to see if it could really work. I would say the same would be true for you. While you could image how it might be to use Unity on a large scale project, you may have to actually do it to know. What I can say is that I have used Object Builder, and because it was designed for the very type of application I'm working on it has worked out just fine for me. Concerning your post representing feedback, it certainly does. However, it is far less likely to actually be of benefit to the Unity development team than if you were to post feedback to their codeplex site. Derek

Ayende Rahien commented on Reviewing Unity

Sun, 24 Feb 2008 23:20:20 GMT

Chris, Without introspection, how can you implement startable? Consider the following case: public class Foo : IStartable { public Foo( Bar bar ) { } } public class Bar {} // you can't respond to the TypeRegistered, because you don't have any idea if // Foo is ready for action or not. unity.Register(); // now you can start Foo, but again, no information about that unity.Register(); Also, I wouldn't consider this a flame. This is just a disagreement and pointing out things that I think that are flaws. It would have been a flame if I had to build a project for production with this at its current state. See my posts about SSIS or MS CRM to see what that looks like.

Ayende Rahien commented on Reviewing Unity

Sun, 24 Feb 2008 23:14:32 GMT

Derek, Allow me to apologize. I was unnecessarily snippy. The scenarios I was talking about was the extensions ones, IStartable and IEnvrionmentValidation. You mentioned in the past that you haven't had the chance yet to evaluate other containers. I strongly suggest that you would do so. Like learning new langauges, new approaches are critical for learning. You have to understand something about the way I work. If it is causing me friction, it is banished. I don't want to work on a tool to get it to do the _baseline_ right. As for feedback, what do you think this post has been?

Chris Tavares commented on Reviewing Unity

Sun, 24 Feb 2008 23:09:47 GMT

[Disclaimer: I am the Unity dev lead] Steve, if you have questions about Unity, might it not be better to post them to the Unity discussion boards[0] instead of this completely disconnected blog or the altdotnet mailing list? The returning null is a bug, not a deliberate design decision. It should throw, and I'm currently working out how to fix it. There's an unfortunately interaction with things we can't build and the BuildUp method that needs to be worked out. The fix should be in the next drop. I'm also working on getting better, more descriptive exceptions. We are well aware of the issue with constructor parameters, and are working in it. Startable is actually easy to implement; I'll put an implementation on my blog this week sometime. Thanks for taking a look, it's nice to have some informed flames rather than the uninformed ones I've seen on the mailing list. -Chris

Derek Greer commented on Reviewing Unity

Sun, 24 Feb 2008 23:09:30 GMT

Steve, I would also recommend that you join the discussion on Alt.Net. It would be a little easier to carry on a conversation there about the points you've brought up. For now, I would like to make an observation about the scenario you brought up. The problem you've encountered here was caused by the fact that the among two resolvable types, you instructed the factory to give you back the wrong one. Admittedly, while in this particular case you encountered the problem because of Unity's behavior of resolving types which are actually resolvable without configuration, this could also have happen in other cases where you registered two similar types and simply typed the wrong one. Another point I think is important to keep in mind is that a container functions from two perspectives: the object using Unity and the object being created by Unity. When using Unity directly, this is a factory usage scenario. If you step back and think about this from a factory perspective, the defaults might actually make more sense. If I ask a FruitFactory to create me an IFruit, I certainly would expect that the factory would need some configuration to figure out what to do. However, if I ask a FruitFractory to create me an Apple then the factory has enough information to fulfill my need without configuration. Now, Ayende and others might argue here that I should never ask my IFruitFactory to create me an Apple in the first place, but that is really another issue. The default we are talking about here only becomes relevant when you are actually requesting concrete types. If you don't ever find the need to do this, Unity's defaults aren't really an issue here. If you do ever want to do this, I would argue that telling the container that your should build an "Apple" when "Apple" is requested is unnecessary. If you want to discuss this further, let's do so on Alt.Net.

Derek Greer commented on Reviewing Unity

Sun, 24 Feb 2008 22:31:34 GMT

Ayende, First, while you may know everything there is to know about Object Builder, my comments were not just for you. Second, I'm not sure I caught the two scenarios that you couldn't do with Object Builder. If you want to throw exceptions for types that aren't in the container, you can certainly do that very easily by writing an extension. Third, while I appreciate your opinions about what every container's default behavior should be, I personally have found the default behavior of Object Builder to make the most sense for the types of application's I've developed over the past several years. As I indicated, if you don't like the defaults Unity provides you, these can be changed easily enough. Lastly, I am certainly not saying that Unity is perfect. There are several design choices that I don't like within the CTP version. Given your vast experience working with IoC containers, I would recommend you offer your feedback to the Codeplex team on their site where your opinions might actually have some impact on the final version.

Ayende Rahien commented on Reviewing Unity

Sun, 24 Feb 2008 18:12:14 GMT

Steve, I suggest you go to the alt.net list, there is active discussion around those topics there. If you will send me a list of questions, I can try to answer them (but it probably needs to be a big list). For starter, it is generally preferred to have a singleton container, init in the beginning of the application.

Steve Sheldon commented on Reviewing Unity

Sun, 24 Feb 2008 17:42:23 GMT

Ok, I'm new to this whole dependency injection thing. I decided to start off with Unity. It does seem to me, based on my small amount of research, to be a simple starting point tool. It may not be as full featured, but it was easy to hook up. So having no experience with any other tool in this realm, I make these comments. I found the returning of null to make debugging exceptionally hard. I also ran into a problem with the default behavior to just create an object rather than throw an error. In my case I was experimenting with injecting the container via the constructor. I registered the container's own instance with itself. But then in one of my classes, instead of saying the constructor required IUnityContainer, I mistyped and said just UnityContainer without the I. Well, unity just went ahead and created a new one, but since it wasn't configured when I next tried to create an object inside the instance it through a null reference error. When trying to debug this, I first started off putting a breakpoint on that creation that failed, and looked at the UnityContainer object with quickwatch to see if I could understand what it was doing. But as Oren notes, there is no way to look at the items registered within the container. If the purpose of unity is to be simple and easy to use, I actually have to agree with Oren that the defaults are counter to that goal because they make it more difficult to troubleshoot things not being hooked up correctly. This isn't to say that these features aren't nice, they are. But they're poor defaults. I'd rather have overloads like GetOrNull<>, sort of like how LINQ has Single, and SingleOrDefault. If that makes sense? One more thing, I'm having a hard time finding guidance on how to use DI. Things like where is the container created, do i create it globally? As a singleton? Pass it around? Recreate when needed? Etc. etc. What's a good approach? That seems like a good paper for the P&P team.

Ayende Rahien commented on Reviewing Unity

Sun, 24 Feb 2008 16:14:01 GMT

Um, Derek, I am well aware of the history of Object Builder. And while I find OB 2.0 significantly better than the OB 1.0, it is not really interesting. I is still overly complex and not well suited for the task at hand. Strategies and policies are very abstract concepts, which you have to beat with a stick t get them to do what you want in many cases. As a simple example, it is as if all you variable definitions were object. Sure, this give you a lot of flexibility, but it is a real PITA. And no, you can't base something like Windsor on OB. Not without doing a huge amount of work. In fact, more work than if you started from scratch. I can't speak for the other containers, but I doubt that it would be a good base for them as well. I just gave two scenarios that are 1) impossible, 2) hard to do with unity. Yes, it is a good thing that OB has a container (not sure what is valuable in a generic object factory, to tell you the truth), but it is not really exciting by any mean. I see those defaults as bug. As I said before, defaults matter, a lot. I haven't seen a good way to make Unity throw an exception whenever it hit one of those obstacles. And I am not interested in any invasive approach. Saying that Unity doesn't require configuration is wrong. It requires extensive configuration, via invasive attributes, on all your types, to handle anything by the very simple approaches. Re: null values. That is a bug. You give the object invalid values. There are such things as optional dependencies, certainly. But the constructor is generally not where you put them. And, as I mentioned before, this approach means that now you get errors that are far harder to trace and debug than the explicit message from the container. Please don't make assumptions about the way Windsor works. They are inaccurate. Both in terms of what it can do and what the design concepts are. Monolithic are certainly not there. I hope you noticed the number of times that I mentioned that this was a first release, CTP, alpha, etc. Yes, I know that this is not the final version, and I haven't reviewed it as such. I have merely 3.5 years experience working with containers and dependency injection. That is a tad over the lifetime of Object Builder. My comments are not coming from pure academic background, they come from my experience of throwing just about everything that I could at the container, figuring out how to architect applications with DI, embedding notions of zero friction development and transparent infrastructure. In that time frame, I had the chance to develop web applications, window applications, messaging application, and probably a few more that I forget. Those moved from the simple monolithic blocks (I had to learn why this approach was bad) to the extremely dynamic ones (I have application that I need to update on the fly, without stopping the normal operation of the application). Based on that experience, I can state that those design decision leads to much long troubleshooting cycles, tedious debugging and fragile systems. Default matters, and I strongly believe that Unity have the wrong ones.

Sergio Pereira commented on Reviewing Unity

Sun, 24 Feb 2008 15:37:25 GMT

I guess we won't be seeing a Binsor cousin (Boonity?) anytime soon :)

Derek Greer commented on Reviewing Unity

Sun, 24 Feb 2008 15:30:49 GMT

When evaluating Unity, I think it is helpful to understand the overall design approach. First, Unity is comprised of the Unity Container and Object Builder. Object Builder is a component which was first developed in August of 2005 to provide dependency injection/inversion of control capabilities to the Composite UI Application Block. It was subsequently incorporated by Enterprise Library version 2.0 for building up all the application blocks. Both the Composite UI Application Block and Enterprise Library created domain specific containers for their own needs. Object Builder itself is really an object factory pipeline which can be used for a large range of concerns. At a high level, it works by chaining together build strategies using the Chain of Responsibility pattern. Strategies are chained together to affect the desired overall object creation (e.g. first look for type associations, second look for dependencies, third create the object with its dependencies, forth set properites, fifth call desired methods, etc.) Object Builder can be used to create a number of different kinds of inversion of control containers, as well as other components responsible for the creation of objects. Object Builder could be used to build Windsor, StructureMap, Spring, or other containers. Unity is the arguably long overdue out-of-the-box container for Object Builder. It provides a facade to Object Builder, and configures a number of strategies for performing dependency injection/ inversion of control. Unity exposes the extensibility of Object Builder through Extensions, and as such you can make Unity do anything that Object Builder can do. So while Unity itself is new, the heart of Unity (Object Builder) has been around roughly as long as the other containers. Concerning some of the default choices of Unity, such as automatically resolving unknown types and returning null for unresolved types, this can be configured to work however one wishes. Unity takes a different approach than many of the other containers in that it doesn't require unnecessary configuration. If it knows how to create an instance of a type then it creates it. In my opinion, this is actually a very reasonable default to be expected from a factory. Concerning the default behavior of returning null when nothing can be resolved, this is actually where Unity shows itself to be less intrusive than does some of the other containers. While Unity facilitates the ability to control what happens when a dependency cannot be resolved (through Extensions), by default it doesn't impose upon all objects the requirement that all dependencies be required. In many cases, components are designed to take parameters which are acted upon if present, but ignored otherwise. For example, some components may be designed to take advantage of an ILogger if made available, but otherwise perform the tasks it is concerned with without logging. Using a container like Windsor, you don't have this flexibility. Windsor invades your design with its own requirements. Concerning lifetime support, this is actually an area being reconsidered by the Unity team in response to a few of us who have been giving feedback to the CTP. Check out the unity codeplex discussions to find out more information on this. Choosing constructors is also another area being reconsidered. Because Object Builder was designed for the CAB and because Unity reflects many of the characteristics of Object Builder, many of the default choices of Unity make the most sense when used within composite/plug-in style applications like CAB. This is true of the project within my company. This may not be true for more traditional, monolithic applications which rely upon a central configuration file and set of known components. Overall, I'm glad to see Unity arrive on the scene. Choices are always good. Derek