Project Architecture

Saturday, October 4, 2008 11:13 AM

I read and loved the series of posts called The Onion Architecture by Jeffrey Palermo. As he put it:

The main premise is that it controls coupling. The fundamental rule is that all code can depend on layers more central, but code cannot depend on layers further out from the core. In other words, all coupling is toward the center. This architecture is unashamedly biased toward object-oriented programming, and it puts objects before all others.

Sweet! Everything a good architecture astronaut such as myself would love. Well, I thought I’d see how well it performed down here where the oxygen is breathable. I’m currently working on a side project for a buddy at work and thought that it would be the perfect test bed as there isn’t a hard deadline for it.

So, here is our “Agenda Management System”. Basically it’s going to expose city council voting records in new and interesting ways.

This is the actual solution. Two of the projects you see exist in every project I create no matter what the chosen architecture is: _build and Tests. _build contains deploy scripts and all of my project dependencies that aren’t “out of the box”. The Tests project contains all of my unit tests (there aren’t many – yes, I suck at this still). The other three projects make up the “onion”.

The most interesting parts of the solution to me are the dependencies. You can see here that Core doesn’t reference anything. That means everything my domain objects and services could possibly need have to live within the Core project. Sounds reasonable until you realize they will at some point need data from the database and to log information. The details of those concerns aren’t “domain” type things of course so they live in the infrastructure project. But Core doesn’t reference Infrastructure! Oh my.

This is where the Dependency Inversion principle comes into play. Basically, anything the domain layer could need that isn’t a “domain” type of concern is split into a contract and implementation. The contract (interface) lives within Core and the implementation lives within Infrastructure. The two are tied together only once at application startup.

Full Solution

Hopefully the image to the left isn’t too tiny to see, but basically there are three players required to make this work smoothly. The class IoC in Core is a static container for the interface of an inversion of control container that will resolve interfaces for me. The InversionOfControlContainer in Infrastructure is the implementation of the container defined in Core. At application startup in the Global.asax, I tie the two together.

So in Global.asax.cs you’ll see this:

protected void Application_Start()
{
IoC.Initialize(new InversionOfControlContainer());

You can probably imagine that all I'm doing in "Initialize" is setting a private static variable that will be referenced throughout the rest of the application’s lifetime. For example, a method on IoC is:

public static T Resolve<T>() { return iocContainer.Resolve<T>(); }

And I use IoC like this:

IoC.Resolve<IUnitOfWork>().Begin();

Of course, note that in this situation, both the interface IUnitOfWork and it's implementation are in Infrastructure, but the use of IoC is the point :)

Well, hopefully that conveys my implementation of The Onion Architecture. I must say, this is something that I’m finding extremely pleasant to work with. Due to the fact that Core doesn’t reference Infrastructure, I’m forced to find solutions strictly in terms of my domain and the repositories. Very cool stuff indeed!

Happy coding!

Tags: .net, architecture, ioc

Why I Would Leave

Tuesday, August 19, 2008 9:36 PM

Today at work I was talking with a couple of friends about leaving the company and the reasons why we would. In addition to this, I was contacted earlier in the morning by a recruiter and then again later in the afternoon by another. So my mind spent a fair amount of time today pondering the idea of leaving my current employer in search of greener pastures. I think these are some of the things that would push me from dreaming to action.

Learning. This is the big one. I’m currently a Lead Programmer Analyst – this is the top of the tree for our programmers. Usually titles at my company are merely the result of time in service or luck rather than a declaration of skill. However, many of my peers believe that I’m not only at the top of the title pool, but that I’m one of the top talents as well. This sounds great and comfortable and all, but I don’t quite buy it. I feel like I have so much to learn and so much growing to do as a developer. I would love it if I were given the opportunity to join a team where instead of being the mentor, I had mentors that could teach me great OOP, TDD, DDD, Agile, etc. I read tons of blogs and try to pull in a good tech book as often as time allows, but I’m only making so much progress learning these things on my own. I would leave in a heartbeat to work with a team where these things are valued or even mandated by all.

Community. I love the local .net user group. We also have an internal user group called DEVLOOP (Developing Excellence Via Leveraging Object Oriented Principles) that I co-started a couple of years ago. Both of these make for great mingling with others who seem to truly enjoy what they do for a living. In general though, I feel like I’m surrounded by people who merely have a job that happens to be in IS. You know, people who you go to lunch with and the last thing in the world they want to talk about is work. How cool would it be to be surrounded by people who shared your passion?!

Freedom of Time/Dress/Location. Maybe I shouldn’t have read The 4-Hour Workweek by Tim Ferris, but it’s too late now and I can’t stop thinking about it! The 8-5 40 hours a week in dress casual mantra sucks. Even if I couldn’t trim my work week down to only four hours, a little license would be nice. I’ve pushed for the 9/80 work week* several times with my current employer, and it is always shut down. And that’s not even cutting down on the total work time! So anything that would allow me to dress as I please, work an alternate schedule, and maybe even work from home would completely rock. As long as I could still pay the bills, I would also take a significant pay cut for something that allowed me to take more frequent and longer vacations. You know, kind of like part time except that you work in full time spurts rather than only a few hours every day all year long. I almost counted this one as “the big one”!

Appreciation. It would be very cool to work for a company where the developers were considered assets rather than merely expenses that are necessary evils required to get the job done in today’s environment. It would also be cool to work in an environment where developers were enabled in their job rather than mired in the bureaucracy that so many companies use to police their people. Trusting the experts to be great at what they do and appreciating them for it – now that would rock.

Now there are many specific things that I could cite about where I work that one might count as reasons for leaving, but I don’t give them much weight in the grand scheme of things. It seems to me that no matter where you work, there will be things you don’t like, people you don’t like, or company practices and policies that you just think could be so much better. These things simply don’t matter in the end. I say chase the things that make me happy and ignore the rest. If I run from the things that make me unhappy, I’ll be running forever and will never be truly happy. Unless it’s simply the running that you enjoy :)

* 9/80 work week: allows the worker to accumulate 80 hours over a two week period in only 9 days instead of the standard 10 giving the worker a three day weekend every other week.

Happy coding!

Tags: work

Site Update

Monday, July 7, 2008 6:46 PM

Well, I made a couple of big changes this weekend.  First, I decided to forget building an entire website myself. What a colossal waist of time that would have been! Well, maybe not a complete waist as I would have learned a ton. But time isn’t exactly a resource I have a lot of. Second, I decided to not go back to using GeeksWithBlogs. So, I downloaded the latest version of BlogEngine.net and uploaded it to my hosting account.

That last part is what gave me a bit of trouble. My current hosting provider is Godaddy and getting the blog going wasn’t nearly as easy as it should have been (in my opinion of course). Below are the troubles I had and the solutions I found after much googling.

First problem was simply getting the blog to run. This is the one that took forever. Thankfully I ran across a blog by the spoiled techie titled godaddy setup with blogengine.net (step by step). He nailed the solution exactly and I was up and running soon after.

The second problem I had was adding a new user that could log in so I could delete the out-of-the-box “admin” user. Turned out (lost the link to this one) that all I needed to do was wait a bit after creating the user. Not sure what’s up with that, but after walking away for a bit and coming back, I could sign in with my new admin user and delete “admin”. I can only assume this has something to do with the session. Maybe BlogEngine.net is caching the users or something.

The last problem was with setting up the smtp account so the site could email me the comments and so the contact form would work. I did have to create an email account with godaddy so that I had a username and password to use, but it turned out that I had to use “relay-hosting.secureserver.net” instead of the one they told me to use. Figures.

Anyhow, everything is up and running now. I can now think more about content rather than starting from scratch and being possibly months away from my first post. An updated resume will probably be my first addition (you never know!).

Happy coding

Tags: blog, godaddy

My Development Philosophy take one

Saturday, May 31, 2008 5:59 AM

Recently I had a discussion with a colleague at work about a way to speak to future developers that join or take over our projects. The idea was that we could simply add a "developer's note" to the solution items so it would live with the rest of the code in source control. I personally couldn't think of a better place for a piece of documentation like this.

After our discussion he spent some time and mocked up a sample developer's note and sent it my way. The idea was that I would customize it to suit me because we came to the conclusion that these developer notes should be a bit personal and should come from the lead developer of the project in question and I happen to be the lead developer on this specific project. All good so far, but in the mock up he include a brief introduction that initially stated his (or a made up) personal development philosophy. Excellent idea I thought. As I started to write my personal philosophy I realized that I didn't have one! I kept writing different things I thought were good ideas only to delete them after thinking that they were just good ideas but didn't really make a very good philosophy. It dawned on me that I have never really sat down to define for myself what I truly believe is a good developer or what makes a good developer or what makes for a good development philosophy. I didn't have a personal mission statement, if you will.

So the research and soul searching began... and this is what I found and the conclusion I came to.

First, some nuggets I found while doing a bit of googling:
Hallmarks of a great developer
Why I’m a better software developer than you
Why Good Programmers Are Lazy and Dumb
How To Become a Better Programmer by Not Programming
Skill Disparities in Programming

The last two are especially good ones. Well, everything from Coding Horror is awesome in my opinion!

Now then, where does all of this leave me? After reading those articles and many others, and after doing a ton of plain old soul searching, I think this should do it:

My personal development philosophy is simple: strive to accomplish the task at hand as well as you can given your current skill set and always strive to improve your skill set.

Now that I look at it, it seems more like a personal philosophy towards life rather than specifically a development philosophy. It also isn't a statement that would help a developer understand the code-base s/he was about to dive into. I guess I'll keep pondering and researching...

Tags: meta

Mocking with rhino mocks follow up

Friday, May 23, 2008 1:11 AM

This is just a quick follow up to my Mocking with Rhino Mocks post.

You can see the entire thread here, but the essence of it is this.

DynamicMock creates a mock where all unexpected calls are ignored with no error. So, if we were to create a dynamic mock and then set an expectation that a method on it is called twice, there would be a requirement for two calls, but a third cal would just be ignored rather than cause an error.

If we absolutely want the behavior of an exact number of calls, then use CreateMock instead of DynamicMock. Nice and simple solution :)

Tags: .net, tdd