Loading ...
Sorry, an error occurred while loading the content.

RE: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

Expand Messages
  • Derek_Greer@Dell.com
    If I haven t made this clear yet, let me do so now .... I started participating in this discussion only to offer my opinion on Unity. I have not criticized
    Message 1 of 299 , Feb 20, 2008
    View Source
    • 0 Attachment

      If I haven’t made this clear yet, let me do so now ….

       

      I started participating in this discussion only to offer my opinion on Unity.  I have not criticized any other product, have not encouraged anyone to switch to Unity, and haven’t criticized anyone for choosing any other product.

       

      I fully appreciate your opinion.  What I don’t understand is why all of you seem to be trying to create groups here.  “Derek, I have to say … I’m going to take the blue team’s side here and say that the red team sucks.”  This isn’t a competition.

       

      Derek

       

       

      From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On Behalf Of Ayende Rahien
      Sent: Wednesday, February 20, 2008 10:05 AM
      To: altdotnet@yahoogroups.com
      Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

       

      Derek,

      I join Jeremy's opinion about the tooling from P&P. They are target to a completely different audience.

      I do like Prism, and I really like the approach to developing it that the P&P is taking.

      Let me put this another way, there is a high likelihood that if I need to build a WPF app, it would be (at least initially) based on Prism.

       

      I am somewhat biased there, though. :-)

       

      The different audience problem is a significant issue.

      Can you give me one thing that I can get from the P&P that would be a significant improvement over my current stack?

      The P&P stuff is useful if you are building from the naked CLR, but that is not a scenario in which I am interested at.
       

      On 2/19/08, Derek_Greer@... <Derek_Greer@...> wrote:

      I thought that was probably the case.  The fact that there are no assets you like out of anything they've done seems to suggest a hint of prejudice.  This may not be the case at all, but I think you can see how such a position would appear from an outsider's perspective.  The team seems to be going out of their way to make assets like Prism and Enterprise Library more approachable by the OSS community, but it seems many here are opposed to using anything they do on sheer principle.  Perhaps instead of following the YAGNI principle, they should be following the TAGUI principle … "They aren't gonna use it".

       

      Derek

       

       

      From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On Behalf Of Jeremy D. Miller
      Sent: Tuesday, February 19, 2008 10:41 AM
      To: altdotnet@yahoogroups.com


      Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

       

      I don't use any of the tooling from P&P.  I'm a fan of the P&P team, but I'm not that wild about any of the tooling they produce.  I think you know what I think about the CAB.  The web development stuff around MVP for WebForms is a temporary compromise.  The configuration story for EntLib pretty well knocks that out as useful in my book, and I think there are better alternatives in the OSS space anyway.  I'm not enthusiastic about software factories in general and think they lead to poorly bloated designs overall.  The web service factory stuff might be useful down the line, but that's not rocket science and I prefer to build my own templates on a per application basis.  What am I missing?

      By and large, P&P servers a developer community that's very different from myself, and I would guess most of the people on this list feel somewhat the same.

      The literature they produced in the early days of .Net was very useful to us on early .Net projects.  I wish they'd go back to publishing more guidance instead of frameworks and factories, but that got voted down hard when Glenn Block suggested it on his blog.

       

      ----- Original Message ----
      From: Derek Greer <dbgreer@...>
      To: altdotnet@yahoogroups.com
      Sent: Tuesday, February 19, 2008 11:26:15 AM
      Subject: RE: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      I think we can both agree on that.  However, if I may ask a question of you in complete seriousness and with absolutely no malicious intent, are there any Patterns & Practices assets that you do use?

       

      Derek

       

       

      From: altdotnet@yahoogrou ps.com [mailto:altdotnet@ yahoogroups. com] On Behalf Of Jeremy D. Miller
      Sent: Tuesday, February 19, 2008 10:15 AM
      To: altdotnet@yahoogrou ps.com
      Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

       

      I liked the interaction patterns post, so I'll be looking forward to it.  I do think that DI-ifying EntLib as they're planning makes EntLib much more palatable.  I still don't think I'd ever choose to use EntLib, but I'm much less averse to it when they do a better job decoupling the configuration away.  To finish that off, they're going to have to a get a usable solution for specifying primitive properties first though, and that isn't in the CTP.

      I don't think Unity looks bad, I just don't think it's nearly complete.

       

      ----- Original Message ----
      From: Derek Greer <dbgreer@gmail. com>
      To: altdotnet@yahoogrou ps.com
      Sent: Tuesday, February 19, 2008 11:09:30 AM
      Subject: RE: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      Jeremy, I don't want to get into comparing who is the most open minded or objective here.  I happen to like Unity because it is basically a thin wrapper around Object Builder which I've used for several years and found to be extremely capable.  I started using Object Builder for one pragmatic reason … it was already there by virtual of Enterprise Library.

       

      Concerning checking out other alternatives, I've actually been planning to do just that.  As a matter of fact, I'm considering writing a comparison/history article similar to my article on Interactive Application Architecture Patterns.

       

       

      Derek

       

       

       

       

      From: altdotnet@yahoogrou ps.com [mailto:altdotnet@ yahoogroups. com] On Behalf Of Jeremy D. Miller
      Sent: Tuesday, February 19, 2008 9:32 AM
      To: altdotnet@yahoogrou ps.com
      Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

       

      Derek,  I recommend you look at other tools before getting too excited about Unity.  You're not open-minded until you've looked at other alternatives.


      Jeremy

      ----- Original Message ----
      From: Derek Greer <dbgreer@gmail. com>
      To: altdotnet@yahoogrou ps.com
      Sent: Tuesday, February 19, 2008 10:20:28 AM
      Subject: RE: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      Jeremy, I recommend that you continue using StructureMap J

       

      Derek

       

      From: altdotnet@yahoogrou ps.com [mailto:altdotnet@ yahoogroups. com] On Behalf Of Jeremy D. Miller
      Sent: Tuesday, February 19, 2008 9:10 AM
      To: altdotnet@yahoogrou ps.com
      Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

       

      Why do I want to write my own policies when the other tools do it all out of the box?

       

      ----- Original Message ----
      From: Derek Greer <dbgreer@gmail. com>
      To: altdotnet@yahoogrou ps.com
      Sent: Tuesday, February 19, 2008 10:04:47 AM
      Subject: RE: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      To answer your first question, Unity can do just about anything you want it to.  If you want it to work this way, you can certainly create your own Policies to do that, and from an earlier post from Brad it sounds like there is one provided by ObjectBuilder to do that already.

       

      To answer your last question, I'm not trying to convince anyone to switch from anything.  I'm just hanging out trying to have some edifying conversation with others in my profession J

       

      Derek

       

       

      -----Original Message-----
      From: altdotnet@yahoogrou ps.com [mailto:altdotnet@ yahoogroups. com] On Behalf Of Casey Charlton
      Sent: Tuesday, February 19, 2008 8:54 AM
      To: altdotnet@yahoogrou ps.com
      Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

       

      Let me put it another way then ....

      Windsor can do it the Unity way if you want (just add a facility to

      automagically instantiate) ....

      Why can't I use Unity and prevent it doing the magic?

       

      I don't neccessary want to declare each and every type ... but I do

      want control over it ... so in my current project we have:

       

             private static bool ScanForAndRegisterP resenters( Assembly

      assembly, IWindsorContainer container)

              {

                  bool found = false;

                  Logger.Debug("Scanning assembly {0} for Workhub.Core",

      assembly.FullName) ;

                  if (assembly.FullName. StartsWith("Workhub.Core"))

                  {

                      Logger.Debug("Found {0}", assembly.FullName) ;

                      foreach (Type type in assembly.GetTypes( ))

                      {

                          Logger.Debug("Scanning {0} for IPresenter", type.FullName) ;

                          if (type.IsClass &&

      typeof(IPresenter) .IsAssignableFro m(type))

                          {

                              Logger.Debug("Registering {0} for IPresenter",

      type.FullName) ;

                              container.AddCompon ent(

                                  type.GetInterfaces( )[0].FullName,

                                  type.GetInterfaces( )[0],

                                  type);

                          }

       

                      }

                  }

                  return found;

       

      I don't need to have XML for each and every IPresenter ... but I know

      where and how it was added to the container, I can also interogate the

      container during debug or runtime to check what it knows about ...

       

      Fundamentally ... what does Unity add to my toolbox above

      Windsor/WtructureMa p/etc ?    If the answer is 'magic' then it adds

      nothing as I can make the others do magic too with less than a dozen

      lines of code - is there something else it does better?  Or is it just

      an official MS endorsement of the principles and something they can

      put into EntLib ?

       

      I don't have a fundamental disagreement with Unity ... it is just

      another IoC container after all ... but you aren't making any

      persuasive arguments for why I should switch ... is there a top 5

      reasons why Unity will make my better?

       

       

       

       

      On 19/02/2008, Derek Greer <dbgreer@gmail. com> wrote:

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > "Well ... the expected behaviour should be that the container cannor resolve the outer object either as it cannot satisfy a dependency ..."

      >  

      >  

      >  

      > With the example I provided, there is no outer object to be resolved.  That aside, I derive from your answers that you are in the camp which believes that all containers should require you to explicitly declare each and every single thing that gets created verses supporting the ability to create unregistered, but otherwise resolvable types.   I am in the camp of those  who prefer a container which provides a basic layer of abstraction for dependency creation which on requires configuration for specific types when there is a desire to apply a different strategy (e.g. manage the lifetime as a singleton, give component XYZ its own special instance, map those using interface ISomethingizer to a concrete instance, etc.)  Trying to think about this matter objectively, it seems the latter is the most straight forward solution, and the one that provides the easiest setup and maintenance.

      >  

      >  

      >  

      >  

      >  

      > "the magic in Windsor it just works ... (once you configure the 400 objects you will need into the container)"

      >  

      >  

      >  

      > I would say that Unity also "just works", but it does so with less work on my part.

      >  

      >  

      >  

      > "but to get stuff in the container, I really want to put it there ... if for nothing more than so the next developer who comes along doesn;t have to figure out what magic set of conditions are required to change the behaviour ..."

      >  

      >  

      >  

      > This is a good point to talk about, because you here give a reason why you want it to work this way.  It sounds like you believe that having some central place where the developer can go see a bunch of explicit container configuration is going to be easier to maintain.  This presumes the developer coming in after you understands how the container works.  If the same presumption is given to the developer coming on new to a Unity project, they are going to understand that the default build strategy is to create the object if not affected by any other strategy.

      >  

      >  

      >  

      > "In your example, which ColorPalate should be auto resolved?"

      >  

      >  

      >  

      > There is no other ColorPalate.  The point of the exercise was to provide an example where the type could be resolved directly in order to ask "If it can be resolved, shouldn't it be by default?"

      >  

      >  

      >  

      > "An IoC container shouldn't be about laziness …"

      >  

      >  

      >  

      > An IoC container is about Separation of Concerns.  Dependency Injection in particular is about providing a layer of abstraction between a dependency and the acquisition of that dependency.

      >  

      >  

      >  

      > "(I declared it in an interface, you construct it all)"

      >  

      >  

      >  

      > First, I do use interfaces where appropriate.  Again, the question I really wanted to pose is was given a dependency which could be resolved directly, shouldn't the container resolve it by default?  I'm sure you could agree that I would be hard pressed to demonstrate this with an example using an interface.

      >  

      >  

      >  

      > Concerning this topic, if you haven't read anything on Interface design best practices then I would recommend checking out the book Framework Design Guidelines by Krzysztof Cwalina and Brad Abrams.  It has some good discussion about when you should and shouldn't use interfaces.  Regardless of your stance on this, I think it is a topic worthy of discussion as to whether the use of an IoC container should change the way you would otherwise design classes  (e.g. Billy Bob the developer: "I normally follow the Framework Design Guidelines book when choosing whether to make something an interface or not, but I now make everything an interface because I use Windsor.")

      >  

      >  

      >  

      > Derek

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > From: altdotnet@yahoogrou ps.com [mailto:altdotnet@ yahoogroups. com] On Behalf Of Casey Charlton

      > Sent: Tuesday, February 19, 2008 2:04 AM

      >  

      > To: altdotnet@yahoogrou ps.com

      > Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      >  

      > To: altdotnet@yahoogrou ps.com

      > Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > Well ... the expected behaviour should be that the container cannor resolve the outer object either as it cannot satisfy a dependency ... *unless* I specifically tell it how I want to resolve those, or I tell it where to get them ... I don;t like "magic" things, I like explicit things ...

      >  

      >  

      >  

      >  

      >  

      > To me, the magic in Windsor (and others of that ilk), is that after everything is declared and in the container, it just works ... but to get stuff in the container, I really want to put it there ... if for nothing more than so the next developer who comes along doesn;t have to figure out what magic set of conditions are required to change the behaviour ...

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > In your example, which ColorPalate should be auto resolved?

      >  

      >  

      >  

      >  

      >  

      > The one that is referenced by the hard coded dependency?  Then just let the outer object construct its own dependencies ....

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > An IoC container shouldn't be about laziness (I declared it in an interface, you construct it all), it should be about a centralised and consistent way of constructing objects. A little thought up front shouldn't be too much to ask ...

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > On 19/02/2008, Derek Greer <dbgreer@gmail. com> wrote:

      >  

      >  

      >  

      >  

      >  

      >  

      > Ayende and Casey,

      >  

      >  

      >  

      >                 You two seem to be missing the point here.  First, the purpose of the example was to ask the question "What should be the expected behavior of a class declaring a dependency of type XYZ?"  While I appreciate your enthusiasm over making my example robust for mocking and other scenarios, this isn't really the topic at hand.

      >  

      >  

      >  

      > That said, while my example does use a concrete type for purposes of demonstration, this does not preclude my later use of strategies for declaring this type as a singleton, mapping this to a derived type, filtering this particular type for recursive DI/IoC, or any other strategy.

      >  

      >  

      >  

      > Derek

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > From: altdotnet@yahoogrou ps.com [mailto:altdotnet@ yahoogroups. com] On Behalf Of Ayende Rahien

      > Sent: Monday, February 18, 2008 6:23 PM

      >  

      >  

      >  

      > To: altdotnet@yahoogrou ps.com

      > Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > I would say that the code is not good in the first place.

      >  

      >  

      > You have a concrete dependency here, and that is bad from the point of view of applying a lot of the container goodness.

      >  

      >  

      > This range from mocking to AOP to decrators.

      >  

      >  

      >  

      >  

      >  

      > This is especially true if you use this is done recursively. You lose control over what is a service and what is not.

      >  

      >  

      >  

      >  

      >  

      > The "explicit" approach sucks, yes. No one wants to register 200 comonents by hand.

      >  

      >  

      > That is why we have auto registration and auto wiring.

      >  

      >  

      > And no, you don't need Binsor for that.

      >  

      >  

      >  

      > On 2/18/08, Derek Greer <dbgreer@gmail. com> wrote:

      >  

      >  

      >  

      > I agree with Brad.  I find the Unity approach much more natural.  That said, I think the difference in opinion stems from how one is first introduced to the concepts of IoC.   My first exposure was through Object Builder.  Object Builder itself isn't a container, but rather an "Object Factory Pipeline Framework".   To some degree, I think learning about IoC through Object Builder prepares you to think more openly about what a container should be.

      >  

      >  

      >  

      > The question here really isn't what all the other containers do, but what the natural expectations are for a type declaring a dependency.  The following shows an example property injection scenario:

      >  

      >  

      >  

      > [Dependency]

      >  

      > public ColorPalate ColorPalate { get; set; }

      >  

      >  

      >  

      > Here, some type has declared that it has a dependency on an ColorPalate.  From a purely IoC perspective, what should we expect to happen here by default?  Should the container create a new ColorPalate, should it return nothing, should it return an exception, or should it do something else entirely?  From a usability perspective, I would argue that a new ColorPalate should be created given no other configuration has occurred to designate that this type is a singleton, that the receiving type hasn't been configured to receive some special instance, etc.   It's a bit subjective to talk about what is the best way, but I think we can objectively consider what is the easiest way.  Is it easier to require all types be declared through configuration, or is it easier to facilitate dependency injection by default?  Obviously, the easiest way is to allow people to declare their dependencies without configuration.

      >  

      >  

      >  

      > Derek

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > From: altdotnet@yahoogrou ps.com [mailto:altdotnet@ yahoogroups. com] On Behalf Of Ayende Rahien

      > Sent: Monday, February 18, 2008 12:12 AM

      >  

      >  

      >  

      > To: altdotnet@yahoogrou ps.com

      > Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > unity.Resolve<RandomObjectNotInCo ntainer>()

      >  

      > It will attempt to resolve that through the container, instead of throwing.

      >  

      >  

      > On 2/18/08, Derek Greer <dbgreer@gmail. com> wrote:

      >  

      >  

      >  

      > Ayende, I'm not sure I follow what you are saying.   Object Builder provides a DependencyAttribute which allows you to specify a NotPresentBehavior.  The component declaring the dependency denotes whether a new instance is created, an exception is thrown, or nothing is returned if a dependency cannot be resolved.  Can you provide an example of what you are referring to?

      >  

      >  

      >  

      > Derek

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      > From: altdotnet@yahoogrou ps.com [mailto:altdotnet@ yahoogroups. com] On Behalf Of Ayende Rahien

      > Sent: Sunday, February 17, 2008 11:11 PM

      > To: altdotnet@yahoogrou ps.com

      > Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      >  

      >  

      >  

      >  

      >  

      >  

      > The one thing that worry me about Unity is the behavior.

      > It is doing some fairly odd things at the moment. Not from a code perspective, from a design perspective.

      > The decision to make the attempt to resolve an instance at any case, for example, is something that is radically different than all other containers do, and it is something that I have strong objections to on the "don't surprise me" part.

      >  

      >  

      > On 2/18/08, Jeremy D. Miller <jeremydmiller@ yahoo.com> wrote:

      >  

      >  

      >  

      > Honestly, I think it's going to be a perfectly acceptable minimalist IoC container that covers the basics.  I don't see Unity even remotely approaching the big 3 in terms of features.  It certainly won't have the community behind it.

      >  

      >  

      >  

      >  

      >  

      > ----- Original Message ----

      > From: Ben Scheirman <subdigital@gmail. com>

      > To: altdotnet@yahoogrou ps.com

      > Sent: Sunday, February 17, 2008 10:33:23 PM

      > Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

      >  

      >  

      >  

      > There's another way to look at Unity.  Having a usable container of their own means the P&P guys can build DI friendly frameworks, and they seem to be dedicated to the idea of not locking you into their own container.

      >  

      > As long as Unity doesn't suck, that's great.  We're seeing the same trend with MS Test, however I will still advise my clients against it until it comes up to par with other frameworks.

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >  

      >

       

       

       

      Yahoo! Groups Links

       

      <*> To visit your group on the web, go to:

          http://groups. yahoo.com/ group/altdotnet/

       

      <*> Your email settings:

          Individual Email | Traditional

       

      <*> To change settings online go to:

          http://groups. yahoo.com/ group/altdotnet/ join

          (Yahoo! ID required)

       

      <*> To change settings via email:

          mailto:altdotnet- digest@yahoogrou ps.com

          mailto:altdotnet- fullfeatured@ yahoogroups. com

       

      <*> To unsubscribe from this group, send an email to:

          altdotnet-unsubscri be@yahoogroups. com

       

      <*> Your use of Yahoo! Groups is subject to:

          http://docs. yahoo.com/ info/terms/

       

       

       

       

       

       

    • Derek Greer
      Ayende, I would agree with you here. I used this as an example because it s the way it was done within the Composite UI Application Block, but Object Builder
      Message 299 of 299 , Feb 22, 2008
      View Source
      • 0 Attachment

        Ayende,

         

                        I would agree with you here.  I used this as an example because it’s the way it was done within the Composite UI Application Block, but Object Builder certainly supports doing this through configuration.  That aside, my point is not how it provides this flexibility but that it provides this flexibility.  I am utterly opposed to a container not giving me choices J

         

        Derek

         

         

         

        From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On Behalf Of Ayende Rahien
        Sent: Friday, February 22, 2008 8:26 PM
        To: altdotnet@yahoogroups.com
        Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

         

        Derek,

        This is an invasive programming model. I am utterly opposed to it.

        I don't want to have to modify my services to match the container.



         

        On 2/23/08, Derek Greer <dbgreer@...> wrote:

        I think it's best to provide a way to tell the container what should happen.   Object Builder supports this ability with its DependencyAttribute.  In some cases, you may want to designate that you have an optional dependency (say, a TraceSource or an ILogger).  In this case you don't want exceptions being thrown.

         

        Derek

         

        From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On Behalf Of Ayende Rahien
        Sent: Friday, February 22, 2008 6:10 PM


        To: altdotnet@yahoogroups.com
        Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

         

        Okay, here is another something that I completely disagree with. The container should never return null, unless you are using TryXyz that make it explicit that this is what is going on.

         

        I want to get a nice exception like:

        "Could not find component for IFoo"

        I don't want to get an exception like:

        "Object reference not set to an instance of an object"

         

        On 2/22/08, Derek_Greer@... <Derek_Greer@...> wrote:

        BTW, while the point here is that different containers work differently, I wanted to point out that with your example Unity would actually return null,  not throw an exception.  Had you given the key "SQL", the normal behavior would be to return a new instance of SqlConnection.  That said, it does throw an exception if provided the key due to a current bug.

         

        Derek

         

         

        From: altdotnet@yahoogroups.com [mailto:altdotnet@yahoogroups.com] On Behalf Of Ayende Rahien
        Sent: Thursday, February 21, 2008 5:24 AM
        To: altdotnet@yahoogroups.com


        Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

         

        Simple example where it matters:

        container.Register<IDisposable, SqlConnection>("SQL")
           .Register<IDisposable, OracleConnection>("ORA");

        container.Get<IDisposable>();

        Windsor would return SqlConnection, Unity would throw, not sure what StructureMap or Spring.NET would do

        On 2/21/08, Jeremy D. Miller <jeremydmiller@...> wrote:

        Gimme:

        2/ That you can replace the implementation of the container. Even if they use interfaces, there are subtle differences between containers that would really trip you.

        And I'm a happy camper.  I think that they (BCL team) could live within a boundary like so:

        public interface IServiceProvider
        {
            T Get<T>();
            T Get<T>(string name);
            IList<T> GetAll<T>();
        }

         
        for all the stuff that needs to happen within the BCL.

        Jeremy D. Miller
        The Shade Tree Developer
        jeremydmiller@...

         

        ----- Original Message ----
        From: Ayende Rahien <Ayende@...>
        To: altdotnet@yahoogroups.com
        Sent: Thursday, February 21, 2008 6:14:17 AM
        Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

        That is based on several major assumptions.
        1/ That the IoC tool will be a good tool by our standards. The BCL team is fairly paranoid in many respects. It has to cover lot of scenarios, but I think that they take it too far. (Abolish internal from the BCL!) I doubt that a container built in that environment would be very useful. I am very afraid of the 79% solution.
        2/ That you can replace the implementation of the container. Even if they use interfaces, there are subtle differences between containers that would really trip you.
        3/ That is would be exposed to external clients, rather than being an internal BCL tool. See point 1.
        4/ That is wouldn't require 2 MB of XML and 60 GB of XSD to work with. (Yes, cheap shot, I know. )

        On 2/21/08, Jeremy D. Miller <jeremydmiller@ yahoo.com> wrote:

        If we had a good IoC tool built into the BCL itself, and the MS tools teams made all the configurable code DI-able, I'd call that a huge win.  No more goofy one-off Xml hell configurations every time a different team releases a new tool.  Just look at the constructor function of whatever thing it is that you need to instantiate, and you know exactly what to do with configuration.  "Push" configuration is soooo much easier to deal with than "Pull" configuration.

        Does anybody out there actually enjoy mucking with web.config files and WCF or Remoting configuration Xml?

         

        ----- Original Message ----
        From: Ayende Rahien <Ayende@Ayende. com>
        To: altdotnet@yahoogrou ps.com

        Sent: Thursday, February 21, 2008 5:59:43 AM
        Subject: Re: [altdotnet] "Unity" IoC from Microsoft has been released in CTP..

        So?
        Why is this a scary thought, there is _already_ a container in the CLR. IServiceProvider implementors are just that.
        Considering the cost of doing a good container, I doubt that it would be comparable to any of the existing containers. Building a trivial IoC is... well, trivial. 
        Building a good one takes a lot of time and effort.

        On 2/21/08, Derek_Greer@ dell.com <Derek_Greer@ dell.com> wrote:

        Here's a scary thought for you guys.  What happens if they decide to bake in a container directly into the .Net Framework?  We've been told that some of the Acropolis features are going to be incorporated into a future version of the framework.  From what I've heard, Acropolis had its own object factory pipeline based inversion of control mechanism.  I wonder if this will be one of those features to get rolled in.

         

         

        Derek Greer

         

         

         

         

         

         

         

         

      Your message has been successfully submitted and would be delivered to recipients shortly.