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 Neimke >> [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.<http://www.windowslive.com/campaign/thenewbusy?tile=multicalendar&ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5> >> >> _______________________________________________ >> ozmoss mailing list >> [email protected] >> http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss >> >> >
_______________________________________________ ozmoss mailing list [email protected] http://prdlxvm0001.codify.net/mailman/listinfo/ozmoss
