>From memory, they use the approach that I am suggesting - although they use a
>kind of hybrid approach where they also use the ServiceLocator from memory.
>That's just because they figure that they need to use Unity in any examples
>they publish I think :-) <grin />
Kind Regards, Darren [email protected] http://2010wave.blogspot.com
From: [email protected]
To: [email protected]
Subject: RE: Dependency Injection recommendations for SharePoint
Date: Mon, 19 Apr 2010 01:34:10 +0000
Have you seen the Patterns and Practices Guidance at
http://www.microsoft.com/spg that has some IoC examples I believe. Cheers,
Jeremy ThakeSharePoint EvangelistMicrosoft Virtual Technology Specialistm: +61
400 767 022 – b: wss.made4the.net – t: @jthakeFounder of SharePointDevWiki.com
From: [email protected] [mailto:[email protected]] On Behalf
Of Darren Neimke
Sent: Monday, 19 April 2010 8:00 AM
To: [email protected]
Subject: RE: Dependency Injection recommendations for SharePoint The beauty of
making your "Presenter" as the Composition Root is that it's all testable from
there down - without SP dependencies.
Kind Regards,
Darren Neimke
[email protected]
http://2010wave.blogspot.com
From: [email protected]
To: [email protected]
Subject: RE: Dependency Injection recommendations for SharePoint
Date: Sun, 18 Apr 2010 16:56:03 -0700
So that's the path that I considered taking when I went down the path that I
recommended to you. In the end, I felt that there weren't sufficient benefits
to be gained by injecting myself into the pipeline (I'm assuming that you wrote
a HttpModule?) and using a ServiceLocator (which I prefer to avoid mostly). So
my approach still had a custom WebPart base class (to do the bootstrapping) but
then I just did the DI direct from there to a Presenter class.
Kind Regards,
Darren Neimke
[email protected]
http://2010wave.blogspot.com
Date: Mon, 19 Apr 2010 09:52:04 +1000
Subject: Re: Dependency Injection recommendations for SharePoint
From: [email protected]
To: [email protected]
I modified my Web Parts and layout pages to inherit from new base classes that
expose a reference to the service locator via a protected read-only property.
It's not terribly elegant, but works OK for the time being.
On Mon, Apr 19, 2010 at 9:49 AM, Darren Neimke <[email protected]>
wrote:So I presume that you are using a ServiceLocator within the request to
gain access to the services?
Kind Regards,
Darren Neimke
[email protected]
http://2010wave.blogspot.com
Date: Mon, 19 Apr 2010 09:46:18 +1000
Subject: Re: Dependency Injection recommendations for SharePoint
From: [email protected]
To: [email protected]
In case there was any outside interest to this, I ended up writing my own very
simple service container that gets reconstructed for every new HTTP request.
I'd still be interested in hearing anybody else who used a service container in
a SharePoint project, and how it worked out for them.
Cheers,
Joe.
On Mon, Apr 12, 2010 at 4:54 PM, Joseph Clark <[email protected]> wrote:The
SharePoint solution I'm developing integrates SharePoint with Confluence, so
its primary purpose is to provide web parts and layouts that can be added to
SharePoint pages that render content from Confluence via web services (it also
integrates with the Enterprise Search libraries and the Microsoft SSO Service).
I guess this is slightly different from a 'stereotypical' SharePoint
application in that I barely touch the Content DB at all. Additionally, the
solution is intended to be deployable in to any old site collection, so I
assume it has to be as unobtrusive as possible so as not to clash with other
custom developments which could be installed.
I'm in the process of re-developing it to support concurrent releases against
SharePoint 2007 and SharePoint 2010, so I have just finished refactoring a
~2000 line static singleton class into loosely coupled services that may be
implemented diffrerently for either SharePoint version. The services are
code-complete and now I am searching for an elegant way to wire up the
dependencies at runtime.
The solution is small enough that I could get away with just writing something
simple to link the dependencies, but the solution could be growing in the
future and I want to reduce code maintenance going forward.
I like your model of using the Web Part as the point of composition for your
services, but since my solution is 'view' heavy and 'model' light (ie. most of
the code deals with manipulating and scrubbing HTML and delivering javascript
to the client), I'd ideally like to achieve the composition one level highter
than the web parts.
Thanks for your input!
Hotmail is redefining busy with tools for the New Busy. Get more from your
inbox. See how. The New Busy is not the too busy. Combine all your e-mail
accounts with Hotmail. Get busy.
_________________________________________________________________
The New Busy is not the old busy. Search, chat and e-mail from your inbox.
http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3
_______________________________________________
ozmoss mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
