So I presume that you are using a ServiceLocator within the request to gain
access to the services?
Kind Regards, Darren [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!
On Mon, Apr 12, 2010 at 4:32 PM, Darren Neimke <[email protected]> wrote:
It would be nice to know a bit more about the nature/type of application that
you are developing.
For most of my SharePoint solutions I have not bothered with an IoC container
but have instead, loaded service settings and connection strings directly from
configuration and then manually injected them into something like a Presenter
class from my WebPart code class.
So I still use DI, but I don't bother with using a separate container - I just
use (for example) my WebPart class as the composition root in my code file.
But again, it might depend on what your solution looks like.
If you are interested I have blogged a code-centric sample of my approach:
http://2010wave.blogspot.com/2010/02/sharepoint-architecture-part-2-mvc.html
But you might also typically use an additional "Presenter" class on top of what
I have in that article.
Kind Regards,
Darren [email protected] http://2010wave.blogspot.com
Date: Mon, 12 Apr 2010 16:23:52 +1000
Subject: Dependency Injection recommendations for SharePoint
From: [email protected]
To: [email protected]
Hi List,
As a budding SharePoint developer, I was hoping there are some people on
the list here who can provide some guidance and/or anecdotes on
selecting a suitable IoC container for a custom SharePoint solution.
I started investigating this today and have become somewhat dismayed at
how inflexible it seems to be to deploy a container inside a SharePoint
site.
Most containers I have looked at so far (Spring.NET, Autofac, Castle
Windsor) recommend modifying global.asax with a custom class that
inherits from SPHttpApplication. Because our SharePoint Solution may be
deployed within arbritary SharePoint sites by the customer(s), am I
correct in assuming that this approach would make our product
incompatible with a customer's own potential global modifications?
An alternative I have read for Autofac is to insert Autofac's custom
HttpModules that control the container setup and tear down into the
request pipeline into the SharePoint site via web.config. I have not
fiddled with the SharePoint web.config before but seem to recall reading
blog posts that discourage it because you either have to hack it during
your solution deployment, which won't work in 100% of deployment
scenarios, or use SPConfigModification, which has a gross API.
I'm at the point now where I am considering rolling my own extremely
simple container just so I don't have to deal with the deployment
minefield.
Does anyone have some experiences to share which might help enlighten
me? :)
Cheers,
Joe.
The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with
Hotmail. Get busy.
_______________________________________________
ozmoss mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
_________________________________________________________________
The New Busy is not the too busy. Combine all your e-mail accounts with Hotmail.
http://www.windowslive.com/campaign/thenewbusy?tile=multiaccount&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_4_______________________________________________
ozmoss mailing list
[email protected]
http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
