Steve Eichert

Are you a Mort, an Elvis, an Einstein...or a Nobody?

Scott Bellware has an excellent post entitled “Mort or Elvis: A Question for a Bygone Era” which is right on the money.  If we’re going to make the software development profession a better place we need to take a fresh look at how we’re building tools and who we’re targeting when we build them.  We can’t stand still and assume our assumptions of yester-year are still valid, especially if they weren’t ever valid.   I’m not sure if or when JetBrains is releasing their standalone IDE for .NET but I have a feeling if it ever does come about there will be a lot of .NET developers jumping off the sinking VS.NET ship.

But I want Flexible, Easy to Change, & Hard to Break!

Tim Ewald’s latest post points out the major problem we all face when designing services…we can’t have everything we want!?!?!  Tim presents the following three desires:

• A flexible system that can evolve
• A system that's easy to build without knowing anything about the XML layer that we're all relying on
• Code that is easy to write and hard to break

He goes on to say that we have to pick our preferred approach and understand the implications of that chosen approach.  Unfortunetly I think Tim is right on the mark.  Although it would be great if we could create a system based on services that gave us all three it just isn’t realistic.  What do we do?

I think the answer depends largely on what type of system you’re developing and how you’re using services within that system.  If you’re creating a set of services that’s sole purpose is to be consumed by others then you definitely want to make sure that you do everything in your power to ensure that those services can be versioned and stay usable at all times, no matter how many versions you deploy.  In this type of scenario you want to always keep your messages clearly separated from any internal representations or structures.

What happens if you’re building a set of services whose primary purpose is to provide one of your own applications with the data and functionality it requires?  Does the same level of separation need to be applied for services that serve very different purposes?  What if the services that you’re providing are focused on CRUD like behaviour necessary for some of your other services?  Is it realistic to think that your domain and contracts will be able to evolve completely independently?  If I add a new field to my backend system which then ends up on my domain object won’t it also need to end up on my contract if you have a service that is used to create new records in your backend system?  In this type of scenario would it be so terrible to have support within your architecture for your domain objects to be turned into contracts without requiring them to be two completely separate things?

While general guidance on how services should be developed is extremely important I think we often make the guidance too black and white.  We need to look at the things that are important to us and understand what implications that has on how we develop our services.  It would be wonderful if we could have it all but that simply isn’t realistic.  Every design decision has a set of associated design tradeoffs that have to be understood.

WSDL First Service Development

Craig, Tim, and Aaron have been having a nice discussion about WSDL first services development.

• The Perils of WSDL First
• Craig urges overkill, XmlSerializer sky is not falling
• A few thoughts on “The Perils of WSDL First”
• The Perils of WSDL First (Again)
• Craig remains jumpy about XmlSerializer and element order
• DataContractSerializer and element order 

Enjoy!

Could our Contracts also act as our Translators?

In my previous two posts I talked about developing services contract first and how it leads to having the messages sent and received by our service defined completely separate from our domain layer.  In my “Designing services contract first” post I talked about having a translator class that has the responsibility of converting our contracts to our domain objects and our domain objects to our contracts.  While that class is pretty simple I wonder if the translation logic could live inside our contracts like so:

namespace MyCompany.Contracts {
   [DataContract]
   public class CustomerContract {

     public CustomerContract() {}
 
     public CustomerContract(DomainLayer.Customer customer) {
        this.Name = customer.Name;
    }

     [DataMember(Name=”Name”, Order=1, IsRequired=true)]
     private string name;
     public string Name {
        get { return name;}
        set { name = value;}
     }
     
     public DomainLayer.Customer ToDomain(Contracts.CustomerContract customerContract) {
              DomainLayer.Customer customer = new DomainLayer.Customer();
              customer.Name = customerContract.Name;
              return customer;
      }
  }
}

So rather then having a separate translator class we have our contract class support being constructed via our associated domain class as well as being converted to our domain class via a ToDomain() method.  The obvious downside is that the contract and domain objects are now coupled together.  The advantage is that everything related to your contracts (including translation) is in one place rather then being spread out across 2 (or more classes).  What do you like better, a translator class, or a slightly smarter contract?  If the behaviour on our contracts is hidden behind our service boundary do we really need to have our contracts be strictly “data classes”?

Designing services Contract First

We’ve recently been having a lot of discussions about how we develop our services.  We’re using WCF (Indigo) to develop our services so we get to let it handle a lot of the plumbing for our services.  We develop our services by creating an interface that defines our service contract and then create a concrete implementation of our service by creating a class that implements our service interface.  All well and good.  When we get into the implementation of our services we start to feel all the uber-SOA dudes of the world give us bad looks.  We’re currently doing the following things that most SOA fanatics would beat us over the head for:

1) We’re not applying the rule that I wrote about way back when.  Web services should have a single parameter.  This means that instead of something like this:

public class CustomerService {
   public Customer FindCustomer(int customerId) { /// }
}

we should be wrapping our customerId up in a DataContract so that our services can be versioned as it evolves like so

[DataContract]
public class FindCustomerRequest {
  [DataMember(Name = “CustomerId”, Order=1, IsRequired=True)]
  private int customerId;

  public int CustomerId {
     get {  return customerId;}
  }
}

public class CustomerService {
   public Customer FindCustomer(FindCustomerRequest request) { /// }
}

2) We’re passing our domain objects back and forth in our services.  So our domain objects are being decorated with [DataContact] and [DataMember] attributes.  Since 99% of the time our services need to return a message that looks exactly like our domain objects we’ve been doing just that and returning them as is across our service boundry.  In order to separate our services implementation from our domain layer we would ideally have a separate DataContract defining our messages that can be transformed into our domain objects.  So instead of…

[DataContract]
public class Customer {
  [DataMember(Name=”Name”, Order=1, IsRequired=true)]
  private string name;

  ///yada yada yada…

  public SaveObjectResponse Save() { //…}
}

We should have our domain object with no DataContract/ DataMember, a separate DataContract used only by our service, and a translator class that converts between the two….

namespace MyCompany.DomainLayer {
  public class Customer {
     private string name;
     public string Name {
        get { return name;}
        set { name = value;}
     }
  }
}

namespace MyCompany.Contracts {
   [DataContract]
   public class CustomerContract {
     [DataMember(Name=”Name”, Order=1, IsRequired=true)]
     private string name;
     public string Name {
        get { return name;}
        set { name = value;}
     }
  }
}

namespace MyCompany.ServiceTranslators {
   public class CustomerTranslator {
       public DomainLayer.Customer CustomerFromContract(Contracts.CustomerContract customerContract) {
              DomainLayer.Customer customer = new DomainLayer.Customer();
              customer.Name = customerContract.Name;
              return customer;
      }

      public Contracts.Customer ContractFromCustomer(DomainLayer.Customer customer) {
            Contracts.Customer customerContract = new Contracts.Customer();
            customerContract.Name = customer.Name;
            return customerContract;
     }
   }
}

While the sample code for the sample above isn’t too bad, imagine how repetitive and boring this could get   None-the-less it does provide a clean separation between your service and domain layers which helps ensure that changes in our services don’t directly affect your domain layer as well as vice versa.  With tools like the Web Services Software Factory the grunt work required for implementation your services using the above method can be reduced to a couple runs of their wizards.  But as you know I don’t like wizards.  Could there be a better way?

Should my Unit tests hit my database?

The below was my response to a comment on my Trouble testing ActiveRecord post.

There is a small subset of tests that should hit the database. These include any logic that involves complex queries or where clauses that you’re unsure of and/or complicated save operations involving things that make you uncertain.

The remaining logic within your application most likely doesn't need to hit the database for testing purposes. The more tests that hit the database the slower the test suite is to run. Personally I want my tests to run as fast as possible and to hit the database the least number of times as possible.

That certainly isn't to say tests should never hit the database, just that it should be the exception not the rule.

Web Services Software Factory

Patterns and Practices recently made available a drop of their Web Services Software Factory toolkit.

The Service Factory is a cohesive collection of various forms of guidance that have been build with the primary goal of helping you build high quality connected solutions in a more consistent way with less effort. In addition to the forms of guidance you may have already seen from the patterns & practices team, there is a new form of guidance in here, called a guidance package, that allows guidance to be automated from inside Visual Studio 2005 through the use of a wizard-based dialog than can be modified (by an architect perhaps) to fit the needs of a specific solution.

The frist drop includes a reference implemention as well as a set of Guidance Automation recipes for helping automate the development of services using WCF/Indigo.  Below is a list of some of the recipes I came across during my experimentation:

• Create WCF Solution – This builds a nice big solution with seperate projects for all your contracts (service, data/message, fault), as well as your service implementation, data layer, business entities, business logic, host, client, and kitchen sink.  The package does a good job of seperating our everything into distinct projects which helps to make the point that things should be be clearly seperated.  The structure that was created for my “CustomerService” was as follows:
• CustomerServiceBusinessEntities
• CustomerServiceBusinessLogic
• CustomerServiceDataAccess
• CustomerServiceDataContracts
• CustomerServiceFaultContracts
• CustomerServiceServiceContracts
• CustomerServiceServiceImplementation
• CustomerServiceHost
• CustomerServiceClient
• Create Data/Fault Contract – This has a couple different options including creating a data contract or fault contract via a wizard, or via code snippets.  I hate wizards so I can’t see ever using the wizard to create my data contracts.  The amount of time it takes to navigate around the data grid to define your contract would be much better spent in the VS.NET editor.  Do we really need a wizard for everything? 
• Create Service Contract – This allows you to define the contract for a service again providing both a wizard and code snippet option.  If you like wizards your going to love the P&P team.
• Create Service Implementation – This allows you to create a service implementation by selecting a service contact.  Those familiar with writing code will likely skip this one as well and use the wonderful SHIFT+ALT+F10 keyboard shortcut to implement the service contact after inheriting their concrete implementation for the proper interface (aka: service contact)
• Create Service Contract Translator using Wizard– This little beauty allows you to map your business entities to your data contracts.  While I couldn’t actually get this to run it seems like a nice utility that can help reduce the amount of grunt work required when you translate all your messages into your entities and vice versa. Update: It’s working, something was hosed on my home installation of WinFX).  An example below shows a translator created to translate my Customer data contract into my Customer business entity.  Pure Fun!

public class TranslateBetweenCustomerAndCustomer {
       public CustomerServiceDataContracts.Customer TranslateCustomerToCustomer(CustomerServiceBusinessEntities.Customer from) {
      CustomerServiceDataContracts.Customer to = new CustomerServiceDataContracts.Customer();
       to.CustomerName = from.CustomerName;
       return to;
   }

    public CustomerServiceBusinessEntities.Customer TranslateCustomerToCustomer(CustomerServiceDataContracts.Customer from) {
      CustomerServiceBusinessEntities.Customer to = new CustomerServiceBusinessEntities.Customer();
      to.CustomerName = from.CustomerName;
      return to;
   }
}

• Decorate Type as Data Contact – This allows you to right click in a class and select for it to be decorated as a data contract.  A [DataContract] attribute is added to the class and [DataMember] attributes are applied to all properties.
• Validate Data Contact – This allows you to right click in a class and have the data contract validated.  Amazingly the data contract produced by their wizard validates quite well!

Overall there seems to be some pretty useful nuggets of guidance within the first release.  I’m very interested to see the project progress and mature.  I just hope the wizard to coding ratio doesn’t get too ridiculous.

Mocking Castle's ActiveRecord

Ayende has a couple posts that were sparked by my post on my troubles testing ActiveRecord objects.  His posts point out how you can mock Castle ActiveRecord:

• Advance Mocking Scenarios With Active Record (using Rhino Mocks)
• Testing ActiveRecord objects

Very good information, thanks Ayende!

Impact of Overtime on Productivity

Trouble with Testing "ActiveRecord" objects

I’ve recently been experimenting with making some changes to our domain layer to help simplify our design and reduce the number of useless objects that were cropping up throughout our code base.  In our previous model we had “Manager” classes that, well, managed stuff.   Our managers closely followed the Repository pattern as defined in Domain Driven Design.

public class CustomerManager {
   ObjectManager objectManager = new ObjectManager();
   public SaveObjectResponse SaveCustomer(Customer customer) {
     return objectManager.Save(customer);
   }

   public bool DeleteCustomer(Customer customer) {
     return objectManager.Delete(customer);
   }

   public List<Customer> FindAllCustomers() {
     return objectManager.FindAll<Customer>();
   }
  
   // etc…
}

What this resulted in was a whole bunch of classes that looked a lot like the above.  I’ve used the ActiveRecord pattern a fair amount in the past so in an attempt to simplify our design we ended up adding some methods directly on top of our domain objects so that all of the above code disappeared.  To make them dissappear we added a base entity that defines a number of methods for saving, deleting, and finding domain objects.

public abstract class BaseEntity<T> {
  static IDatabase<T> db = new Database<T>();
  public SaveObjectRespnse Save() {
    db.Save(this);
  }
  public bool Delete() {
    db.Delete(this); 
  }
  public static List<T> FindAll() {
    db.FindAll(); 
  }
}

public class Customer : BaseEntity<Customer> {}

While this cleaned up our code and made it so we could get rid of a number of objects it has caused one issue.  We now have statics, which means we have a testability issue.  In order for us to enable things to be tested we needed a way to inject a IDatabase<T> into our Customer class.  Since our base entity has static methods that require the database it requires our database instance to be static.  This prevents us from using dependency injection to inject our mock database for testing.  As a short term solution I added a means for registering and unregistering a database like so:

public static void RegisterDatabase(IDatabase<T> dbToRegister) {
  db = dbToRegister;
}

public static void UnRegisterDatabase(IDatabase<T> dbToUnregister) {
  if(db == dbToUnregister) {
    db = defaultDb;
  }
}

While this works its far from ideal. 

[Test]
public void DoSomethingThatDoesNotNeedTheRealDatabase() {
  MockDatabase<Customer> mockCustomerDb = new MockDatabase<Customer>();
  mockCustomerDb.FindAllResult = myDummyCustomerList;
  Customer.RegisterDatabase(mockCustomerDb);
  try {
     // do some stuff that calls Customer.FindAll();
  }
  finally {
    Customer.UnRegisterDatabase(mockCustomerDb);
  }
}

As a result of having some ugliness due to the use of statics I think we’ll likely move to having a “Manager” like base class that supports generics.  This will have the same advantages of the current implementation and cause less issues when it comes to testing. 

public class Repository<T> {
  public SaveObjectResponse Save(T item) {…}
  public bool Delete(T item) {…}
  public List<T> FindAll() {…}
}

I wonder how the folks who are using Castle’s ActiveRecord handle this issue.  From browsing through their code base it doesn’t appear that they make it so you can mock out the ActiveRecord’s behavior easily which typically results in a lot more tests hitting the database then necessary.

The Development Abstraction Layer

Joel’s latest article entitled, “The Development Abstraction Layer” offers a peak inside what happens within successful software companies.  While I don’t agree with everything Joel says I think he (not surprisingly) hits a lot of things right on the head.  Over the last few years I thought about going out on my own to startup a software company countless times.  The fact that I wouldn’t have had any abstraction layer is what always stopped me.  Well that and the fact that I didn’t have an idea I really believed in

Anyway, for those people working at software companies Joel’s latest article is a must read.  As a “techie” he understands what it takes to get the most out of his programmers.

CLR via C#

A couple weeks ago I picked up Richter’s second edition to Applied .NET, CLR via C#.  I’m about half way through and I can see why everyone loved the first edition.  Rather then focusing on all the syntactical sugar that the various .NET languages provide he focuses on what’s really important, the CLR.  And it just so happens he covers it using my preferred programming language, C#.  The book is packed with a ton of great information so if you haven’t picked it up yet, I recommend you get on it.

Quality With a Name

In case you didn’t know I taught Jim Shore everything he knows.  So go read my thoughts on what constitutes “good design” via Jim’s latest article, “Quality With a Name”.  Sam (who also learned everything he knows from me) has some nice reflections on Jim’s article as well.

Boot Camp