Hmm, I'm not sure it's "better". I'd probably call out YAGNI.
You have converted a set of nicely named methods into lots of classes, contructors, etc and a whole bunch of messy XML config. In this instance I do not see this added complexity providing much more power.
I can see your motivation however, so I'll keep this method in mind for the future... Thanks for sharing.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "S#arp Architecture" group.
To post to this group, send email to sharp-arc...@googlegroups.com
To unsubscribe from this group, send email to sharp-architect...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sharp-architecture?hl=en
-~----------~----~----~----~------~----~------~--~---
I am not certain that you actually would derive much of any benefit of doing this (tempted to call YAGNI), but even if you did, I think I like the way you would do it with MEF better:
http://kozmic.pl/archive/2009/04/05/meffing-with-castle-windsor.aspx
It would get rid of the web.config modifications at the very least.
Howard van Rooijen wrote:
Hi,
I was just exploring the S#arp Arch codebase with NDepend to try and get a better understanding of the inter-dependencies of the various components (screenshot attached).
I discussed the diagram with my devs during a code review, the general consensus was that Northwinds.Web has too many dependencies - and we felt that it should not be directly dependent on Castle.Core, Castle.MicroKernel, Castle.Windsor, log4Net, MVCContrib.Castle, NHibernate, FluentNHibernate and Northwind.Core.
Most of these dependencies only exist because of initialisation requirements and I was wondering if anyone had done any refactoring work to eliminate them? Something like the Bootstrapper pattern - which encapsulates initialisation requirements - as it would make the Global.asax file so much cleaner:
http://weblogs.asp.net/rashid/archive/2009/02/17/use-bootstrapper-in-your-asp-net-mvc-application-and-reduce-code-smell.aspx
Thanks for any input.
/Howard
I tried to reference that class but I cannot.. hmm maybe i am doing something wrong and need to understand what I am really trying to do...
Thanks for all the replies (it’s nice to see one of my questions has finally sparked a discussion)!
The reason I started the thread in the first place is that one of the more junior developers, during the code review, asked:
Why is there a hard dependency on Northwind.Data and more specifically NHibernate – I thought this was supposed to be a loosely coupled architecture?
And on the specific NHibernate dependency:
Shouldn’t it be something more like:
IRepository repository = ServiceLocator.Resolve<IRepository>();
repository.InitialiseSession();
From a project delivery perspective - I fully agree with the YAGNI sentiments aired - as we have more important business features to implement (and we are).
From an architectural perspective, if the vision of S#arp arch is truly a "solid architectural foundation for rapidly building maintainable web applications" for developers of all abilities and the Northwind sample is the exemplar of that - then the YAGNI argument starts to sound more like "it works, so why bother changing it?" rather than the stance we should be taking of “this is how you loosely couple and facade your dependencies to minimise the impact of change and increase maintainability”.
From the responses in this thread, it seems that two different requirements are getting intermingled and they should really be separated:
1. The mechanical requirement of getting all referenced assemblies into the bin folder of the web project & configuration entries so the app executes properly
2. The architectural requirement of decoupling layers and creating facade around dependencies.
For point 1) is sounds like the community has lots of different solutions – for more advanced (and disciplined developers) merging all projects into one uber project reduced compile-time tax. For more variable teams, enforcing separation via multiple projects has an advantage (incidentally we solved the performance tax issue by setting CopyLocal=false and adding a MSBuild script that creates a junction point from the libs folder to a new libs folder under debug and then added this path as a new probing path in config – it resulted in our compilation time reducing by 50% without any structural changes).
During the code review one of the devs asked about the “VS Solution Folder Structure” as he didn’t understand why had a project named “Infrastructure” rather than “Data”. It wasn’t until I pointed him at Jeffery Palermo’s Onion Architecture post that it clicked in his mind. We’ve integrated Lucene.Net into the solution – is it really something that should live in the Data project? Or is it actually an infrastructure dependency?
For point 2) it looks like there is some more work to do in S#arp Arch.
Eric hits the nail on the head when he talks about supporting developers of all skill levels - S#arp arch should be the “pit of quality” that all devs, regardless of experience fall into.
I'm sorry, but I love code behind pages :)
So, I'll change it for "adding code to a view, a reference to the
System.Data(...)"
I guess that many still forget how easy is to add to much responsibility to
a view by using <%%> in the aspx file (that is, when you're using the web
forms view engine)
Luis