Northwind.Web Dependencies - Bad code smell?

[Howard van Rooijen]

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

[Jonathan Parker]

I'm not fully convinced that it's a smell. Global.asax.cs is less than 100 lines of code in the Northwind project.

One of the comments on the blog post you linked to summarizes my opinion quite well.

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.

[Howard van Rooijen]

Hi,

Thanks for the feedback. 

It just seems slightly backwards that you would decouple all of your dependencies with interfaces, then use the glorious fluent auto registration syntax to elegantly fill your container with concrete types from the assemblies loaded within the applications' app domain only to reintroduce the dependencies and the tight coupling in order to initialise them!

/Howard

[Bill Barry]

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:

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

---

[Kyle Baley]

I've struggled with this as well. It seems by the time I add all the dependencies in any MVC app I write, it takes up the entire height of the screen in the References list. But I've always been able to justify it enough that I don't bother looking into removing the dependencies.

On the one side: The fact is, the web project *does* have at least an indirect dependency on all those libraries. You can remove them from the references somehow but in the end, they need to be deployed with the app.

On the other: If I switch one container for another, I shouldn't have to go through the list of references trying to figure out what libraries other than Castle.Windsor are affected.

Speaking of Windsor, it kind of has the same problem anyway. As soon as you decide to go with Windsor, you automatically need references to MicroKernel, Core, and often DynamicProxy2. Ditto with Iesi.Collections and NHibernate.

Kind of talked around in circles but I've already typed all this out so someone's gotta read it to make me feel better.

On Fri, Apr 24, 2009 at 8:34 PM, Bill Barry <after....@gmail.com> wrote:

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

---

[Joe Lowrance]

I think you summed it up pretty well in the second paragraph.

[Kyle Baley]

Yes, but that's not a very good argument. In a traditional three tier architecture, a UI project references a business layer which references the data layer. All three need to be deployed with the app but should my UI project have a direct reference to the data layer?

 

For a project where I am the only developer, then the answer is: I don't care. Because I know I'm disciplined enough not to use things in the UI that I shouldn't. In fact, I'm about to start an app where there will be one project. Layers are separated by root folder and tests will be side-by-side with the classes under test. Too early to say whether that's good or bad so far but I like the idea in theory. If it works, it's pretty much the same scenario we have here.

 

The main reason we don't want all these references is so that we aren't tempted to use them when we aren't supposed to. To take an extreme slippery slope example, do you want your views to be able to create an NHibernate Session? Again, if you're disciplined enough, that's not too big a deal. But if you are part of a team that doesn't share your enthusiasm, a clearer separation may be necessary simply to maintain sanity.

[Eric Hexter]

The separation of explicit dependencies really helps when you have developers that are new to this architecture and really new to all of the principles behind it. Separation of Concerns, Solid, ect.  

For developers, like the ones on this thread,  who know where and why dependencies and abstractions should be made, this seems like a nit picking type of argument.  But for developers who are looking to this architecture, because it is  based on good design principles, and are new to the concepts;  Having the dependencies of the ui project separated will force them to ask the question of why is that dependency missing?

Here is how I imagine the conversation in the imaginary programmers head:

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...

Just some thoughts, I went through the same issue with the Code Camp Server codebase and we found that teaching developers the principles behind the separation really took a while to click in and make sense. In our classes where we teach this, the students are really taking all of these concepts on faith, and the experience that there previous architectures did not work for long term maintainability.

When discussing this change I think you need to look at this from a different context than that of an experienced disciplined Object Oriented Developer.

Eric

[Joe Lowrance]

I'm still not convinced. There's nothing to stop a less enthusiastic
team member from adding a code behind page, a reference to
System.Data.SqlServer and connecting to the database and spitting
everything out via a big loop over a DataTable, but I think at some
point you have to just have a little faith that most people aren't out
to do a crappy job and generally don't need to be protected from
themselves.

Joe

[Eric Hexter]

At the end of the day it really boils down to who is S#arp targeted for?  Someone who understands all the principles and the entire stack of each of the oss frameworks or someone who would not go out on their own and put the pieces together if they had to figure out how to make it all work. 

I totally understand the yagni argument. For the projects that my company runs, we have actually gone so far as combine all of the source into a single assembly once we ran out of ways to speed up our build.  I understand the compromises that need to be made and I do not think there is one solution that meets all scenarios. I am not even arguing to make this change but rather to better understand  the question; who is S#arp is for?  

[Howard van Rooijen]

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.  

/Howard

[Luis Abreu]

> I'm still not convinced. There's nothing to stop a less enthusiastic
> team member from adding a code behind page, a reference to
> System.Data.SqlServer and connecting to the database and spitting

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