Steve Eichert

Are objects with behavior bad for SOA?

In most of the discussions I've read regarding SOA the author makes a point of saying that any object being used in a SOA should only contain data and not behavior.  My question is why?  Your object's behavior isn't going to be exposed to the client if they access your objects via your services anyway.  Well that's assuming your services are web services.  Let's for a second forget about the fact that you can have SOA without web services. :-)

In a SOA with web services the request and response for your web services will be defined using WSDL and schemas.  The schemas for your business object will not contain information about the behavior of your objects, so to the clients using your web service it looks like your objects only contain data.  However, in the code for your web service you can use your objects, and their glorious behavior.  Behind your web service you know your going to need to perform basic CRUD operations on your objects so why not make them available on your object rather then through a manager class.  WHOA, but doesn't that create a coupling between your object and the data store?  Absolutely not.  That's what the provider model is for.  If your objects are coded to use a provider to service the CRUD operations you can completely decouple the object from the actual implementation details of how the CRUD operations are performed for your object. 

Do the objects behind your web services have behavior?  Why not?

To cache or not to cache, that is the question

As I talked about several months ago I'm building a very lightweight content management system for one of my clients.  I'm getting pretty close to having a basic system up and running.  One of the final pieces I'll be implementing is “friendly url's”.  Friendly Url's make it so visitors to the site can browse to a url like: http://www.emxtechnologies.com/aboutus.aspx.  If my site (for my .net consulting projects) was actually running my CMS that request would be routed to something like:  http://www.emxtechnologies.com/template.aspx?postingID=40&channelID=1.  Originally I thought I would perform the friendly Url lookup by hitting the database.  As an alternate I'm also considering looping over my channels and postings to find the match. 

If I take the second approach I'll definitely have to add a new CacheEntityProvider provider to my base entity framework.  I was thinking my CacheEntityProvider could just wrap another EntityProvider such as the SqlEntityProvider.  The CacheEntityProvider would sit on either side of the SqlEntityProvider.  When data is requested via Find or Load routines the CacheEntityProvider would look in its internal cache to see if the object was already loaded.  If so the object would be retrieved from the cache and returned, otherwise the CacheEntityProvider would forward on the request to the SqlEntityProvider and then cache the result it provides.  On the other side of the coin would be the persistence of the objects.  During the persistence the SqlEntityProvider would be called to perform the actual persistence to the Sql Server data store.  After saving the object it would be dumped into the cache of the CacheEntityProvider.

At first this seemed pretty straightforward, however, I then started thinking about my related objects.  As an example think about my Posting object.  It has a Template property that returns the Template object configured for the posting.  The declaration of my Template property in my Posting class looks something like this:

public Template Template {
   get {
      if(_template == null)
             _template = new Template(_templateID);
      return _template;
   }
}

Now when the Posting class is cached, so to will its associated Template.  If the Template is then updated the Posting will hold an out of date Template object.  This is not good.  I can either try to write a routine which finds dependencies and invalidates the cache for each of these items, or I could change my property to always load the template (which would them retrieve it from cache if it existed).

public Template Template {
   get {
          return new Template(_templateID);
   }
}

Of course I could still ditch the whole CacheEntityProvider idea all together and perform the friendly Url lookup via the database. 

What does this become when moving to SOA?

public class Order {
   // public properties ...
   public OrderItemCollection OrderItems {
       get {
           if(_orderItems == null)
                 _orderItems = new OrderItem().FindByOrder(this.OrderId);
           return _orderItems;
       }
   }
}

Order order = new Order(5);
DoSomethingWithOrder(order);

foreach(OrderItem item in order.OrderItems) {
    DoSomethingWithOrderItem(item);
}

I'm taking opinions on what this becomes when adopting a SOA.  Opinions welcome!  (I already have an opinion but want to see how it compares)

How do services affect the coupling of objects?

Today when I design my applications I think in objects.  With all the hype surrounding SOA, as well as the strong movement of many in the community towards “service programming” I've started to evaluate how I write applications.  How will the way I create my object model change?  Today I write my applications with entity objects.  These entity objects have data and behavior.  Thats right I put behavior in my objects!  It just feels right.  As I stated many times before I don't like introducing a service layer in front of my application just for the heck of it.  Many people may come running and screaming that I'm creating a coupling between my business objects and the way they are persisted (saved, deleted, retrieved).  It's true.  However, the coupling is only between my objects and a common interface.  I will always need to save, delete, and retrieve my objects.  Whether its against an Xml file, SQ Server database, or across the INTERNET to a Persistence web service.  By abstracting the service used for persisting my objects out into a common interface I'm reducing the coupling.  When I call .Save() on my entity object I can change what “service” it uses with the flip of a value within a configuration file.   If a new requirement pops up that requires me to support a different “service” all I have to do is create the service and again make a change to the con fig file.  Since this post has turned out to be completely different then I anticipated let me leave it at that.  Maybe tomorrow I'll post about what I originally intended :-)

Is anyone creating MSI's as part of their Nant build process?

Testing for equality in unit tests (NUnit)

Today I'm adding a piece of functionality to an application that is changing the results of some calculations.  This in turn makes it necessary for me to update the unit tests that validate the calculations.  For some strange reason the tests are using Assertion.Assert(message, condition) instead of Assertion.AssertEquals(message, expected, actual).  Since we *are* checking that the value returned is equal to the value we expect there is absolutely zero reason to use the Assert() method instead of the AssertEquals() method.  If I could find the guy who wrote the unit tests for this application I'd....um...well....hrm...I think it was ME!?!  What was I thinking? 

Don't make the same mistake, use AssertEquals / AreEqual [1] when testing for equality. 

[1] Assertion.AssertEquals is pre v2.1 of NUnit, Assert.AreEqual is v2.1+ of NUnit

Naming unit test methods

The project I'm currently working has a thorough set of unit tests, and as I said earlier this week unit tests are good.  I am preparing to make an even bolder statement today.  Are you ready....

Unit tests with method names that describe what's being tested are better then unit tests with uninformative method names. 

Today I ran into a test class that was doing a good job testing the functionality of the business object it was targeting, however, I wasn't able to tell that from looking at the green circles in NUnit.  Rather then giving your test method boring names like:

Activate()
ActivateInvalid()
ActivateInvalid2()

Try something more informative (and yes more wordy) like:

CanBeActivated()
CanNotBeActivatedWithInvalidUserID()
CanNotBeActivatedIfItsAlreadyActive()

Think of a name that describes what your testing, and the requirement it relates to.  This helps when others run the full test suite, and it also allows the unit tests to self-document many of the requirements in the system.  Correctly named test methods along with TextDox or NTextDox makes for a simple way to generate basic documentation surrounding the requirements of your system.

How do you name your unit tests? 

Naming unit test methods

The project I'm currently working has a thorough set of unit tests, and as I said earlier this week unit tests are good.  I am preparing to make an even bolder statement today.  Are you ready....

Unit tests with method names that describe what's being tested are better then unit tests with uninformative method names. 

Today I ran into a test class that was doing a good job testing the functionality of the business object it was targeting, however, I wasn't able to tell that from looking at the green circles in NUnit.  Rather then giving your test method boring names like:

Activate()
ActivateInvalid()
ActivateInvalid2()

Try something more informative (and yes more wordy) like:

CanBeActivated()
CanNotBeActivatedWithInvalidUserID()
CanNotBeActivatedIfItsAlreadyActive()

Think of a name that describes what your testing, and the requirement it relates to.  This helps when others run the full test suite, and it also allows the unit tests to self-document many of the requirements in the system.  Correctly named test methods along with TextDox or NTextDox makes for a simple way to generate basic documentation surrounding the requirements of your system.

How do you name your unit tests? 

Validating business objects

Udi Dahan recently posted a response to Are validation errors exceptions?.  In his response he provides an example that demonstrates the way he prefers to perform his validation.

public string Name
{
  get{ return name; }
  set  {
    if ( value.Length > Constants.NameLength )
      throw new ApplicationException("String is too long. Name must be no longer than " + Constants.NameLength.ToString() + " characters.");
    name = value;
  }
}

The main advantage to using this approach is that the business object is never in an invalid state since validation is performed before any property values are set.  Although its very much an implementation detail, the thing I don't like about this approach is that the validation rules cannot be used in the UI to validate the entity.  Since the validation rules are embedded within the property set, our web form has to duplicate the logic, which is not a good thing.  Udi did the noble thing and separated out the actual rule via Constants.NameLength, however, if the rule goes away all together we then have to remove the code in the property set and also remove the RegularExpressionValidator from our UI.  We want a single source for our validation rules so that when the client inevitable changes their mind about what is required we only have to apply the change to a single place. 

I've written a bit about my custom validation framework in various posts in the past:

• More fun with attributes
• CodeDom + Reflection does indeed rock
• Do you use marker interfaces
• Newtelligence data validation

At the heart of my framework is a set of custom attributes that define validation rules for the properties of my business objects.  The custom attributes allow me to tag properties in various ways:

• Required - the property is required.
• MaxLength - the property length cannot be exceed the given length
• MinLength - the property length must exceed the given length
• Pattern - the property must match the provided regular expression
• Compare - the property value must compare to another property value (equality, greater then, less then, etc.)

To continue with Udi's example above his code would become:

[MaxLength(Constants.NameLength)]
public string Name
{
  get{ return name; }
  set  { name = value; }
}

In my current implementation the property value is not validated when set.  However, by using the metadata provided via the custom attributes mentioned above I can add validator controls to my web form to provide validation in the UI.  The way I accomplish this is by reflecting on my business object.  I find each property, and loop though each ValidationAttribute I find decorating the property.  Then each validation attribute is matched up to a validator control, and initialized using the properties of the attribute.  Finally the validator control is hooked up to a the control on the form relating to the property.  There are several possible approaches for relating the property to the control on the form.  The simplest is by simply naming your controls with the same name as the property of the business object (possibly with a prefix/suffix).

Since not all the properties of your object may be set within the UI it is still important to validate the object before calling .Save().  The .Validate() method of the business object uses logic very similar to the UI to perform the full object validation prior to save.  Using this approach does not provide you with validation when each property is set, however, the UI will be doing that.  As a final validation, since we can't completely trust the UI to do its job, we have our .Validate() method which performs a full object validation before attempting to persist the object.

By using the approach outlined above I'm able to define my validation rules in a single location.  I am then able to validate the controls on forms used to edit my business objects, as well as perform the business object validation before a save (just to be sure).

Note: I'm thinking about writing a more detailed article, along with much more code samples on this subject.

Changing my mind about private variable naming

Unit tests are good, no unit tests are bad

Today I've chosen to be the master of the obvious.  Unit tests are a very good thing.  This morning I needed to make a decent sized change to how a piece of functionality within my current project works.  Since I have 20+ unit tests covering the piece of functionality I could very confidently make the change.  If I screwed something up my tests would most certainly come yelling and screaming.

Alternatives, no unit tests are bad.  Last night I had to make a small change to a project with no unit tests.  Since I didn't have anything to confirm that I didn't break the entire app with my “small change” I wasn't very confident.

When going into battle make sure you have a set of unit tests to get your back!

Test Coverage

Business classes often have a bit of overlap among the functionality they provide.  Often times we create manager classes that use one (or more) business classes to perform their job.  When a manager class uses a business class to perform its work how should each of the classes be tested?  Do we test each class individually, and write a bunch of duplicate code?  Or, should we only test one of the two classes?

In the past I've taken the following approach:

• If the manager class is just an in between, meaning it doesn't do anything except hand things off to the business object, I typically write a unit test for the business object, and put a stub test routine in the unit test for the manager indicating that the functionality is tested in the business object.
• If the manager class uses a bunch of business object to perform its work I write unit tests for the manager as well as the business objects.  Since the manager is performing a set of action on the business objects that can't be tested through the business objects themselves these tests are necessary.

How do you handle the testing of overlapping classes?

Vault 2.0 is free....doh!

“With our new pricing for Vault, some readers will note that we have eliminated the "Single User Edition".  Previously priced at $49, this offering was quite popular with self-employed consultants and their ilk.  In place of the Single User Edition product, we have implemented what could be called an "Implicit Single User Edition".  In a nutshell, Vault is now free for one user.  Just download the Vault binaries and install them.  You don't need a serial number at all.  With no serial numbers, Vault 2.0 is hard-coded to behave as if there is one license. “ - http://software.ericsink.com/20040213.html#10151

Doh!  Looks like I hopped on the deal too soon   Oh well.

Total Economic Impact of using ThoughtWorks Agile Development Approach

Do Mock objects and data driven applications fit together?

I'm all about test driven development (TDD).  I think it greatly improves the quality of my code and provides enormous benefits during the refactoring process.  As part of my TDD learning process I've looked at how I can reduce the coupling between my tests by using mock objects.  I had some early success with the development of a “MockEntityProvider“, however, it was short lived.  I still feel a strong need to test that the data stored within my objects is properly persisted to the database.  If the data isn't persisted, it doesn't do me much good to have green unit tests, since it only gives me a partial confirmation that my objects are working as expected.  The problem I have is that many of my objects depend on data in other tables (and thus other objects) which forces me to have my test class coupled to classes besides the one its testing.  I know I could reduce the coupling by using .SQL scripts to populate my database, or by using Xml and DataSets, however, in my current architecture both of those options require a lot more maintenance work then just using my objects (I'll explain why in another post).  Does anyone have any magical way to make working with mock objects in data driven applications bearable?  Even better has anyone found any open source projects that use a database, test the database as part of the unit tests, and also use mock objects?

WS-Eventing for Dummies

If you're trying to keep up with all the WS-Specs out there check out this easy to read introduction on WS-Eventing.

And now WS-Eventing Part II: The Subscription Response!

Are you lazy enough?

I've been called lazy a number of times in various comments on this blog.  Although it's not something most people like to admit, I'm all about being lazy.  Especially when it comes to programming.  Laziness is the number one motivator for a lot of the work I do.  Think for a minute about the work we do.  It can be extremely repetitive!  My laziness forces me into thinking about how to do the work I do with less effort.  By figuring out how to do things with less effort I make it so I can get more done in less time.  Laziness is good.

Do you consider yourself lazy?

Spec #1 - WS-Addressing

I've just read a couple overviews of WS-Addressing and think I understand its intended purpose. 

I was about to write pretty much everything I read on Steve Maine's blog so let me direct you there rather then plagiarize his entire post .  The funny thing is that it took reading another MSDN article for me to *get* what Steve got when he posted his "I think I finally get WS-Addressing" post. 

WS-Addressing helps to define how web services should be invoked, routed, and replied to in a transport neutral way.  Rather then relying on HTTP to carry along the information necessary, we explicitly define it in the SOAP Header for our web service calls.  This not only allows us to invoke web services using TCP, but it also allows us better control over how the response messages from our web services calls are handled.  Rather then always returning to the address of the service/client that invoked the web service we can instead reply to another service or client.  We also have the ability to customize how SOAP fault's are handled.  What's cool is that using this approach we're able to introduce a lot into our architecture.  Instead of limiting ourselves by always having our message response returned to the place that it was invoked from we can introduce all kinds flexibility regarding how the response is handled.  We have the ability to chain web services together, and provide a dynamic pipeline for processing our message.  WS-Addressing is cool, and as Alex Lowe reminded me extremely necessary.

Reference:
Web Service Addressing (WS-Addressing)
Expanding the Communications Capabilities of Web Services with WS-Addressing

Too many friggin specs...

Is it just me or is there way too many friggin' web service specs? 

• WS-Addressing
• WS-I
• WS-Events
• WS-Security
• WS-Trust
• WS-Federation
• WS-Atomic Transaction
• WS-Yo Momma

When can we stop writing specs and get some work done?  Anyone have any really good starting points for beginning to wrap your head around all these specs?  I'm about to get started on some WS extensions to some apps and need to get myself up to speed on all these wonderful specs we now have.  Life was easier without all these specs!

The key to a good design is...

What is the most important factor influencing the quality of an applications design?  How much planning is necessary?  How long needs to be spent on requirements gathering?  How many UML diagrams are necessary?  What can I do before I build an application to ensure the final "product" has a solid design?

Over the years I've asked myself many of these questions.  Unfortunately I wasn't really looking in the right direction.  All the planning in the world can't ensure a good design.  The most important factor influencing the overall quality of a design is...REFACTORING!

Certainly refactoring isn't the only influencer, however, it is the most critical.  During the build (and design) of an application the requirements and assumptions that were driving the design initially will change.  These changing requirements and assumptions will place you in a difficult position.  Do you accept these changes and refactor your application, or do you stick to your guns and swear that you got it right the first time.  I've worked on many projects that have taken the second approach.  Rather then embracing change, and applying what we learned from the changing requirements into the design, we stuck to our guns and tried to convince ourselves that we had it right from the start.  Doing this caused the design to get really ugly.  By sticking with our initial thoughts we were severely limiting ourselves.  We weren't giving ourselves a chance to learn from our mistakes, and we were killing the future maintainability of the application.

When designing your next application remember that you will get things wrong.  Requirements will change.  Your initial design that looked so great, really won't be all that good.  Rather then resisting change, embrace it.  Learn from your early design mistakes and use what you learn to make your design better.  Refactor.

Switching to Rss Bandit