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
