Perceived Complexity

Jan 12, 2010 at 9:42 AM

Hi guys

First up, I'm really enjoying working through your code for this project. Aside from the MEF implementation (which I don't yet understand!) I've got a pretty good handle on how everything works.

On looking at S#arp Arch originally, and now WhoCanHelpME, my first reaction was, wow that's a lot of code, especially for what functionality you actually end up with (I understand that this is a small sample app built on top of a platform which will scale).

I'm always aware that as a C# developer we have a reputation amongst the rails/django types for over-complication and "building rockets" when actually we're creating basically simple CRUD apps which they could no doubt whip up in a day ;-)

I'm not sure where I'm going with this post, I'm certainly not attacking this project, in fact I intend to use significant chunks of this for our next app. Oddly enough, if all this framework code (LinqRepository functionality etc) was compiled into a dll and supplied (along with S#arp Arch) as part of asp.net mvc, then we'd actually be able to write very simple controllers, tasks and tests "out of the box" and no-one would comment on the complexity!

Maybe that's the way forward ;-)

Anyway, I guess I'm just musing, feel free to tear me apart for this and tell me why it's not complicated and not a problem! ;-)

Jon

Ps just to reiterate, I like this project and am absolutely not attacking it in any way!

 

Developer
Jan 12, 2010 at 9:58 AM
Hi Jon,

It is complicated - no argument there. I don't know if you saw the original email Howard sent to the SA community when we released this, but in it he explained the reason. Basically, this app is intended to demonstrate an approach we took to implementing S#arp Architecture when we built www.fancydressoutfitters.co.uk. Obviously as a fully functional ecommerce site, there's substantially more "non plumbing" code in that solution than there is in WCHM, but equally obviously we weren't able to open source that project because we built it for a client who wouldn't necessarily want the guts of their website open to public inspection.

It's also worth pointing out that with the original codebase, a large percentage of the base code - e.g. the LinqRepository, NHib registration, etc - was pulled into reusable libraries. We didn't do the same for this project because those libraries also contain a large amount of other EMCC IP which we reuse on our projects. Referencing the compiled versions of those libraries would have masked a lot of the useful code we were trying to demonstrate, and including the source would potentially have caused us internal problems, so we elected to pull the relevent bits directly into the app.

Hope this goes some way to explaining what you see. I agree that the best approach if you use SA across a number of projects would be to package up some of the framework pieces into core libraries - maybe we should see what would add benefit to SA Contrib...

Regards,
Jon

2010/1/12 jonhilt <notifications@codeplex.com>

From: jonhilt

Hi guys

First up, I'm really enjoying working through your code for this project. Aside from the MEF implementation (which I don't yet understand!) I've got a pretty good handle on how everything works.

On looking at S#arp Arch originally, and now WhoCanHelpME, my first reaction was, wow that's a lot of code, especially for what functionality you actually end up with (I understand that this is a small sample app built on top of a platform which will scale).

I'm always aware that as a C# developer we have a reputation amongst the rails/django types for over-complication and "building rockets" when actually we're creating basically simple CRUD apps which they could no doubt whip up in a day ;-)

I'm not sure where I'm going with this post, I'm certainly not attacking this project, in fact I intend to use significant chunks of this for our next app. Oddly enough, if all this framework code (LinqRepository functionality etc) was compiled into a dll and supplied (along with S#arp Arch) as part of asp.net mvc, then we'd actually be able to write very simple controllers, tasks and tests "out of the box" and no-one would comment on the complexity!

Maybe that's the way forward ;-)

Anyway, I guess I'm just musing, feel free to tear me apart for this and tell me why it's not complicated and not a problem! ;-)

Jon

Ps just to reiterate, I like this project and am absolutely not attacking it in any way!

 

Read the full discussion online.

To add a post to this discussion, reply to this email (whocanhelpme@discussions.codeplex.com)

To start a new discussion for this project, email whocanhelpme@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com


Jan 12, 2010 at 10:05 AM

Hi

That all makes a lot of sense. I realise you've had to compromise slightly to protect your clients etc. and in taking this approach you've certainly given something of real value "back" to the community.

 I definitely think that some of this would sit nicely in S#arp Contrib, especially the LinqRepository/LinqSpecification implementation.

Regards,
Jon 

 

Coordinator
Jan 12, 2010 at 12:15 PM

Yes - the point of the demo is to take all the patterns & practices we used building an enterprise web app and distil them down to a demo - so while it can seem overly complex - it's what's required to enable you to build a web app that is not only testable, scalable but also a foundation for further growth without masses of technical debt.

The ruby / django community may well say we over complicate things - but this architecture is not "astronaut architecture" or "architecture for architecture's own sake" - it's architecture as it should be - a good design, with solid patterns that solve problems that are of both business and technical in nature.

The reason we believe this is because at peak the architecture handled 520,000 page request per day without even breaking a sweat. 

I think in the future Sharp Architecture is going to have to become a little more complex to become simpler - if there are plans afoot to support EF as well as NHibernate - then an ORM specific abstraction will be required. I think there are several things we could do to clean up the architecture to make it become easier to consume - one of the first notions would be to create a SharpArchApplication that inherits HttpApplication and hides a lot of the configuration / wire up boiler plate code and the combined with some more conventions around ORM / View Engine configuration - should help "users" of the platform a lot more.

If you want more info on the MEF / Castle stuff - I wrote a post that covered this in more detail: http://consultingblogs.emc.com/howardvanrooijen/archive/2009/11/12/using-mef-and-castle-windsor-to-improve-decoupling-in-your-architecture.aspx

Thanks for taking the time to check out the code & comment!

 

/Howard