Toph - Early Architecture Decisions

by November 9, 2012 06:29 AM

In Another Gig Completes, I mentioned planning to start a new project to help track consulting gigs. Here I introduce you to:


Project codename named after Toph from the Avatar: The Last Airbender

As I mentioned before, this project is meant not only to help organize my consulting gigs, but also give me a public project and codebase I can point to. I also hope to use the project as blogging fodder. Speaking of which...

Early Architecture Decisions

I've spent the vast majority of my career joining existing projects. There is always that sense of "that's not the way I would have done it". Well, I finally get to do it my way! It was tempting to go crazy with it and implement everything cool I've been reading about recently - whether needed or not, I might add. In the end I decided to go with a pragmatic approach that is much more likely to be a useful example I can point to when talking to developers as I continue consulting.

Visual Studio Projects

I'm still a fan of and will continue to advocate onion architecture (some might say Hexagonal Architecture). One difference you'll find between Toph and what I normally do though, is the lack of an Infrastructure project.

There seems to be a theme going around the blogosphere that is advocating the removal of unnecessary abstractions and part of the theme has been the combining of projects. The idea is that it is perfectly possible to create an architecturally sound solution without using Visual Studio projects to enforce it. In case you're wondering how they "enforce" it, realize that Visual Studio projects won't allow circular references between two projects - whether by directly referencing each other, or indirectly (A - B - C - A would not compile). Therefore if you have a UI and a Core project with UI referencing Core, you couldn't reference UI from Core.  Thus, this usually prevents you from directly doing UI type actions from within Core since you couldn't touch the controllers or view models.

I'm almost always a fan of pragmatic programming. As it turns out, the Infrastructure project never proved that exciting for me as a standalone project. So I just created a namespace within UI called Infrastructure and dumped everything in there. You see, everything usually consider Infrastructure is generally only used during application startup anyway as I'm building up the inversion of control container.

However, I still very much like having my Core separate. It just feels right. So, I decide three projects are all we'll need in this solution

  • Toph (I decided there was no reason to call it Toph.Core)
  • Toph.UI
  • Toph.Tests

Even if I end up adding another project in the future for scheduled tasks (to be run on some application server somewhere), leaving Infrastructure under UI should still be fine. That's because I generally just invoke endpoints in the UI from those background tasks rather than directly dealing with the domain or application's database.


New projects should always be started with the latest and greatest, right? I went with ASP.NET MVC 4 of course. Specifically, I started with the Internet Application project template.

Data Access

That template starts with using a local database and using Entity Framework as its ORM of choice. As expected if you know me, I changed that use SQL Server 2012 Express and NHibernate. To do that...

  1. Delete InitializeSimpleMembershipAttribute. This is the attribute added to AccountController that ensures the database exists and is initialized. There is only one line in there that is needed: WebSecurity.InitializeDatabaseConnection.  I moved that into Application_Start
  2. Delete UsersContext. This is the EF DbContext
  3. Move UserProfile from the Models directory into the domain and kill the EF attributes
  4. Add Fluent NHibernate
  5. Do all the normal NHibernate config and mapping stuff
  6. Change your connection string
  7. Create the database with the single UserProfile table
  8. Run the application

That should do the trick.

Other notables

The only other things I added to the project were Structuremap and my personal code library RobTennyson.Common.

I also stuck with restricting domain access to a Service Layer like I usually do. One difference I thought I'd toss into the mix this time is a bit of CQS goodness (not full blown CQRS, mind you). We'll see how this turns out as the project grows.

Grabbing a copy and playing

If you're interested in playing around with this, but sure you get the code specifically from this commit: 91a19e9f8b

I'll be moving on with the project of course, but at that exact point, the project is still basically just the default template - well, juiced up a bit, but basically still has nothing to do with the real project in it yet.

Happy coding

Tags: , , , ,

What I like About ASP.NET MVC

by March 16, 2010 05:42 AM

I've been asked a lot lately about why one would choose MVC over Web Forms. I'm not so sure about when one should, but I know my default choice is always going to be MVC.

Here are a couple of reasons why

Closer to the metal

With the lack of server controls and postback model, I find myself writing more raw HTML. I like that. Some people won't and that's fine by me. I do.

I meet too many developers who have no idea what the server controls they use actually end up as in the browser. That blows. Some don't even realize the server controls are not real HTML elements. Some don't notice the difference between server and client. I can't remember how many times a developer has asked me if they can call C# from HTML or if they can call javascript from the codebehind. I know the answer to both is "yes" in a round about funky way, but you know what I mean.

Forcing developers closer to the metal is forcing developers to realize what is actually happening. That has to be a good thing.

Forces a more user friendly design

You know how in web forms you can build an entire workflow in a single page using the postbacks? You know, selected index change event on a dropdown, lookup buttons, sorts, filters, wizard controls, tab controls, etc. All these things causing postbacks and firing events and the URL never changing. It's all happening in place due to the magic of web forms and viewstate.

Well, I find that doing anything like that in MVC is hard. And I love that! The result for me is that I end up rethinking my view. I find my putting myself in the shoes of the end user and concentrating more on how to allow them to accomplish the goal as simply as humanly possible. If I really do need richness or dynamic data to accomplish the task, I'm going to do it in an AJAXy way because that's easier than posting back and forth. For the end user, that's a very good thing!

In a nutshell, I tend to focus more on accomplishing goals and less on editing data when I build with MVC.

All the other goodness

Google MVC vs. Web Forms and you'll find a ton of other opinions. I agree with just about every reason you find that favors MVC :). They're all good and whatnot, but the above two are my favorites.

Tags: , , ,

Branching Strategy

by November 24, 2009 08:35 AM

Check out for some good discussion about branching strategy.

This is in reply to a question about our branching strategy on my current project at work.

  • Main - similar to "trunk". Contains the latest and greatest code and is always ready to deploy to production.
  • Dev - similar to "branches". Any feature that will take more than one check-in to finish should be done in a branch. This is to facilitate the most important part of main – always ready to deploy. And of course, we check-in frequently as a good practice so branching is pretty important.
  • Prod - similar to "tags". Contains the code that is currently in production. If it's a web app, you only really need one branch in here unless you think you might actually roll back to a previous version. This branch is useful when you need to immediately fix a bug in production but aren't quite ready for main to be deployed. Just because main can technically be deployed, doesn't mean the business is ready for it. The reason you see so many versions in our prod folder is pure laziness. It needs to be cleaned up big time.

And for the other two questions:

When you branch, you need to remember to check in the code you just branched. The icon mentioned is TFS's way of telling you that you haven't checked in the branched code yet.

We get the version number from the version of our core library. Many projects will use a shared settings file or something to ensure all the libraries within a solution have the exact same version - much cooler than the way we do it :)

Hope that helps!

Tags: ,

Paul's Final Iteration

by October 11, 2009 12:16 PM

I was poking around in my data the other day doing a bit of housekeeping and ran across the recoding of Paul Clements' final presentation to devloop before leaving the company. I hated to see it hidden away on my HDD so I decided to chop it up and post it for all to enjoy!

Wise words from a wise man: Paul's Final Iteration


Tags: , , ,

Arrays Lists and some IEnumerable Philosophy

by September 16, 2009 04:36 PM

So I had an "architecture moment" today at work. I was refactoring some code with Jay Smith and while modifying a few classes, we changed a few data types from List<T> to T[] (from generic lists to plain old arrays) at my request. I'll get to why in a moment. Just let it be noted first that doing this caused two things: first it caused a significant amount of work at merge time for one of my teammates, and then it caused a philosophy discussion about why we should or should not bother with plain arrays instead of their big brother List class. And then the conversation veered in the direction of using IEnumerable<T> as return types and the dangers therein.

Inflicted Pain

When we made all the changes, I thought we were doing all the grunt work for everyone else on the team. I hate when what I do causes a significant amount of work for someone else; especially when the change isn't "needed" but is more of a philosophy type change. It turned out that one of the classes heavily affected by our changes was being worked on heavily by someone else. Thus the heavy merge problems for him. Completely my bad.

Array vs List

I have a very strong belief that all code should be self documenting. Therefore, to me, if I make the data type of a property List<whatever>, I feel that is telling other developers that this is a property expecting to be modified (adding and removing things). An array, however, says to the world that here is the final un-modifiable list as it was at object creation. A side result of this belief is that I pretty much never return a List from a method call since there are very few contexts where that makes sense.

Well, there usually is a reason to use List as a data type or return type. Not a good reason, but a reason... I usually see this as a convenience because those lists do get modified by adding dummy objects (like the first item in a dropdown that says "Please Select One") before data binding.

There was one other point mentioned too - performance. Yes, I know, I know. A List is bigger than an array and calling ToList on an IEnumerable is slower than calling ToArray, but not by much. And when I say "not by much", I mean seriously, seriously small amounts. I actually did a bit of testing to be sure and this is the result I got, so this part of the argument isn't worth ever mentioning again.

ToList speed (10,000 calls): 2,089 ms
ToArray speed (10,000 calls): 1,986 ms

ToList size: 16,448 bytes
ToArray size: 16,024 bytes

Total guids created: 20,002,000

The code that generated this result is at the bottom of the post.

IEnumerable Gotcha

When I mentioned that I never return List<T> from a method and always choose T[], it was asked why I don't just return IEnumerable<T> instead of an array.

Do you happen to remember the phrase deferred execution? It basically means that any variable of type IEnumerable<T> might be a list of stuff and it might just be an execution plan that will return a list of stuff as the list is enumerated.

The gotcha in that last statement is that the execution plan will run every time the list is enumerated. Did you notice the last line of the above test result? I did that on purpose to show again that an IEnumerable<T> will execute over and over. This is why even though the size of the list of guids is 1000, the GetNewGuid() method was called over 20 million times during the test!

So, you certainly can be careful when returning IEnumerable by calling ToArray() or ToList() to force the execution plan and return a finalized list. The problem for my little brain is that I constantly forget to do that! I'll run the application or the unit test, see whacky things happen or poor performance, and then go back and fix things properly. Or at least I used to when I was on the kick where every list was an IEnumerable no matter what. Now by default I use an array and only return IEnumerable when deferred execution is my intention (remember all code is self documenting).

Enough already!

Ya, ya... that's enough rambling. I really do hate long winded blog posts! Here's the code I mentioned earlier that generated that result. Happy coding!

internal class Program
   private static int _numGuids;

   private static void Main()
      IEnumerable<Guid> guids = Enumerable
         .Range(0, 1000)
         .Select(x => GetNewGuid());


      Console.WriteLine("Total guids created: {0:n0}", _numGuids);

   private static void MeasureSpeed(IEnumerable<Guid> guids)
      const int iterations = 10000;

      var stopwatch = new Stopwatch();
      for (int i = 0; i < iterations; i++) guids.ToList();
      Console.WriteLine("ToList speed ({0:n0} calls): {1:n0} ms", iterations, stopwatch.ElapsedMilliseconds);

      for (int i = 0; i < iterations; i++) guids.ToArray();
      Console.WriteLine("ToArray speed ({0:n0} calls): {1:n0} ms", iterations, stopwatch.ElapsedMilliseconds);


   private static void MeasureSize(IEnumerable<Guid> guids)
      var startingMemory = GC.GetTotalMemory(true);

      var list = guids.ToList();
      var memoryAfterList = GC.GetTotalMemory(true);
      Console.WriteLine("ToList size: {0:n0} bytes", memoryAfterList - startingMemory);

      var array = guids.ToArray();
      var memoryAfterArray = GC.GetTotalMemory(true);
      Console.WriteLine("ToArray size: {0:n0} bytes", memoryAfterArray - memoryAfterList);


   private static Guid GetNewGuid()
      return Guid.NewGuid();

Tags: , ,