I haven't been doing a lot of blog posting or work on my own personal projects this past couple of weeks because I've been spending my time reading.  I read the majority of WCF Programming, and have almost finished Release It.

Programming WCF Services is pretty much what you would expect from a book with this kind of title.  Lots of code examples of WCF.  Pretty dry and boring, but still the book goes into more depth than a lot of books on the topic.  The plethora of code is also very handy as a reference guide.  Overall I would recommend the book if you intend on doing any in depth WCF programming.  I do wish the book would have covered how to build better services: service contracts, data contracts, faults.  I suppose those topics are more general than WCF. My rating: 4 out of 5 stars.

Release It!: Design and Deploy Production Ready Software is the best book I've read in a long time.  There's only a couple lines of code in the entire book, yet the book provides excellent insight into design and architecture decisions for building and running robust, scalable, enterprise software.  If there's one take-away from this book, its design your systems to be loosely coupled, don't let a failure in a downstream service or application force your application to fail - build your software to be cynical.

Use timeouts!  Make services asynchronous.  Pay special attention to external integration points: services, networks, databases. Apply circuit breakers at external integration points.  Manage your resources wisely: bandwidth, CPU, and RAM are only so cheap, especially for large enterprise applications in a large farm.  Pay attention to your software once it goes live, don't throw it over the wall to IT. 

Build in monitoring and logging from the beginning, this could mean the difference between 10 minutes of down time and a days worth of down time.  Make your logging messages clear, so that IT can understand them.  Your customer facing software is your company, if your software performs poorly or malfunctions, it reflects poorly on your company, which ultimately shows up as lost revenue.

Again, Release It is an excellent book.  Go get a copy!  My rating: 5 out of 5 stars.

Unfortunately I've read the entire book in less than a week, and here I am without a book to replace it with.  My company was nice enough to give me an Amazon gift certificate, just for doing my job, so I decided to stock up so I wouldn't be without a book again, for a little while anyway.  I just ordered what I would consider to be "the essentials", since they are so often referred to:

• Patterns of Enterprise Application Architecture
• Refactoring to Patterns
• Test Driven Development: By Example

I realized that in almost every project I work on I end up defining a small preconditions assertion library.  I got tired of doing that, so I created a very small argument preconditions library.  That's all this library does - preconditions, that way I can add this to any project without any other baggage to go along with it.

I wanted the precondition library to be readable and short.  This is what I came up with:

Throw.If(regexExpression).IsEmpty();

Throw.If(instance).IsNull();

I think it intention revealing and short to write (especially with intellisense) than traditional precondition checks.  Another nice thing is that is type safe/smart, so only string arguments get string related precondition checks - like IsEmpty().

I checked it into my SVN repository on Google code.

I hate it when I forgot to include subjects in my outgoing email, unfortunately Outlook lets you send email with no subjects without prompting you.  This blog post has some VBA code to add that functionality.  Just remember to change the double quotes to the normal non-italicized flavor.

From Jeff Palermo in the comment section of Hammet's blog post:

I'm, at this point, very concerned that the average Microsoft developer will use ASP.NET MVC not to improve their application design, but merely because it's the new thing. I can see it now: before there was 1000 lines of code in Page_Load. Now there is 1000 lines of code in the controller action.

I found myself doing this today with Rhino Mocks:

[TearDown]

public void TearDown()

{

    mocks.ReplayAll();  // ensure replay was called

    mocks.VerifyAll();

}

I have a few tests in my fixture that don't use mocks, so forcing those tests to have mocks.ReplayAll() in them is just extra noise.  As it turns out calling Replay multiple times is safe, so tests that use mocks of course have already called ReplayAll, but tests that don't use the mocks can forgo having to call ReplayAll() just to have the tear down method run without error.

In case you didn't know, calling VerifyAll in RhinoMocks will throw an exception if you have previously called Replay.

I'm just finishing up building my first deployed WCF service, and over the past couple of months I've learned a lot about WCF - what works and what doesn't from a practical standpoint.  Unfortunately there are still a few areas in which I'm fuzzy.

I was originally treating my WCF proxies like ASP.NET 2.0 web service proxies.  Create a proxy and then let the GC handle it.  This was really useful because I was just injecting the service instance into each of my MonoRail controllers using Windsor.  Testing was nice and easy, and things looked good.

Until last week... I discovered a nasty bug in my web application.  The bug was, that under load, the WCF service would stop responding and timeout.  Come to find out that it's not only recommended to close your client side proxies, but required (at least when using Net TCP binding).

This turned my beautiful code with its inverted dependencies into a mess.  I had to start asking the container on every call for a new proxy since it was getting closed after every remote call.

IMyService svc = IoC.Resolve<IMyService>();
svc.SomeRemoteCall();
svc.close();

I had to do it this way because the remote calls were wrapped in a local service helper object that didn't have any idea about the unit of work, i.e. where the best place to put the Close() call.

When I have some time this week I plan on building a WCF proxy helper that will create a proxy unit of work on a per HTTP request basis.  When the HTTP request comes in, the proxy is created, and when the HTTP request finishes the helper will call Close() on the proxy.  This should allow me to remove the ugly static IoC dependency and use Windsor to inject the proxy instance.

After some research I discovered the MyMeta API used by MyGeneration for DB meta data is now open source under the very liberal BSD license!  That sure makes my life a lot easier since it has a much more fully featured API than I started to build.  Even better it supports multiple RDMS out of the box: SqlLite, MySql, SQL Server, Access, Oracle etc.

This means that I can programmatically walk a database definition using C# in a generic way.  The API is somewhat similar to SMO, but primarily uses OLEDB to pull: DB, table, column, view, index, and sproc definitions from the different providers.

What surprised me is that the MyMeta API has interface definitions for everything; interface definitions that have the same names and properties as the interface definitions I had already created in SQLMigration.  I only had to change the namespace using statements in a few places and add a reference to MyMeta.dll to start using it with my existing code.

I haven't fully tested this out, but assuming MyMeta works as advertised, it should cut back development time significantly.

I finally got one of the harder unit tests for my SqlMigration tool passing.  The interesting thing is that I'm using NHibernate to populate my object graph of objects that describe the database.  I'm just using standard SQL queries that hit the INFORAMTION_SCHEMA tables.  Here's one of the tests:

[Test]

public void ShouldReturnAddressForeignKeys()

{

    ITable address = session.Get<Table>("Address");

    ITable state = session.Get<Table>("StateProvince");

    Assert.IsNotNull(address, "No address table returned");

    Assert.IsNotNull(state, "No state table returned");

    Assert.IsNotNull(address.Columns, "No address columns returned");

    Assert.AreEqual("FK_Address_StateProvince_StateProvinceID",

        address.Columns[4].ForeignKey.Name, "Incorrect FK name");

    Assert.AreEqual(address.Columns[4],

        address.Columns[4].ForeignKey.ForeignKeyColumn, "ForeignKeyColumn StateProvinceID is incorrect");

    Assert.AreEqual(state.Columns[0],

        address.Columns[4].ForeignKey.PrimaryKeyColumn, "PrimaryKeyColumn StateProvinceID is incorrect");

}

Unfortunately I just realized that you can have a compound primary key so I really ought to change ForeignKey.PrimaryKeyColumn to a list ForeignKey.PrimaryKeyColumn[0]...

Using NHibernate for this kind of work probably isn't the easiest solution, but once the mappings are right NHibernate takes care of correctly populating the object graph which isn't trivial because of all the bidirectional associations.  I've definitely learned a lot about NHibernate mappings and SQL Server's INFORMATION_SCHEMA views. NHibernate really is flexible and powerful and NHibernate makes loading a specific object from the database very easy and fluent.  The only "code" I had to write were the XML mapping files besides building a SessionFactory. 

It does seem that using NHibernate to directly query SQL Server is too time consuming development wise especially when other people have already figure this stuff out. If there were am easy way to generate NHibernate mapping files at runtime for a DB I could probably use NHibernate's rich meta data model instead of, or in addition too.  Another possibility is to use MyGeneration's data model or even SMO to populate my entities.

In some ways it seems like I'm reinventing SMO, but at least I have the source code to my version of SMO and my version doesn't have a hard dependency on SQL Server even if SMO has a lot more functionality.