andyfrench.info

I recently had a bit of a brain fade when using Moq. I wanted to check that one method on a mocked class wasn’t called but that another was. Imagine a class like this:

public class Testable
{
    IService _service;
    
    public Testable(IService service)
    {
        _service = service;
    }

    public void MethodToTest(int i)
    {
        if(i <= 0)
        {
            _service.DoSomething();
            return;
        }
        
        _service.DoSomethingElse();
    }
}

I want to test that when if i > 0 only the _service.DoSomethingElse() method is called. I need the mock implementation of IService to throw an exception if the wrong method is called. The solution is to ask Moq to create a strict mock:

using Moq;
using NUnit.Framework;

[TestFixture]
public class TestableTest 
{
    [Test]
    public void MethodToTest_WhenArgumentGreaterThanZero_DoesSomethingElse()
    {
        // Arrange
        Mock<IService> mockService = new Mock<IService>(MockBehavior.Strict);
        mockService.SetUp(x => x.DoSomethingElse());
        
        Testable testable = new Testable(mockService.Object);
        
        // Act
        testable.MethodToTest(1);
        
        // Assert
        mockService.Verify(x => x.DoSomethingElse());
    }
}

When MockBehavior.Strict is used, Moq will throw an exception if any method is called that does not have a corresponding setup. In this case if the DoesSomething() method is called and exception will be thrown and the test will fail.

Read More

I’ve started dipping my toes in the ESRI ArcGIS APIs and wanted to get something clear in my mind - What is a relationship class?
Firstly, I’ve made the somewhat obvious observation that the ESRI concepts around classes, tables, joins etc. are really a layer over the top of relational database concepts. It seems that the ArcGIS tools provide a non-SQL way to design or access the data in the geodatabase – sensible if you want a tool for users not familiar with databases or SQL. However, if you are a developer who is familiar with SQL and databases the ArcGIS interface gets a bit confusing until you can draw a mapping between well understood relational database concepts and what the ArcGIS tools give you.

Tables

Tables in ArcGIS are just the same as tables in an RDBMS. They have fields (columns if you prefer) and rows.
Note that in ArcGIS a table will always have an ObjectID field. This is the unique identifier for a row and is maintained by ArcGIS. If the requirements of your application mean that you need to use your own identifiers then you will have to add a new field to the table (in addition to the ObjectID) and use that to store your identifiers.

Subtypes

Tables can have subtypes. A subtype is just an integer value that is used as a discriminator to group rows together (this is somewhat similar to the discriminator column when using a single table to store a class hierarchy in NHibernate). Note that it becomes a design decision as to whether you represent different feature types as separate feature classes or by using subtypes.

Domains

The term domain pops up all over the place but the explanation for what they are is quite simple.

“Attribute domains are rules that describe the legal values for a field type, providing a method for enforcing data integrity.” ***

That looks very much like a way to maintain constraints to me. There are 2 types of domain:

• Coded-value domains – where you specify a set of valid values for an attribute.
• Range domains – where you specify a range of valid values for an attribute.

Feature classes

First up, a feature class is just a table. The way I think about it is that feature class could have been named feature table. The difference between a feature class and a plain table is that a feature class has a special field for holding shape data – the feature type.
All features in a feature class have the same feature type.

Relationship classes

This is what started me off on this investigation. I visualise a relationship class as just a link table in a database (i.e. the way you would normally manage many-to-many relationships in an RDBMS).
Here are some quotes from ESRI documentation:

“A relationship class is an object in a geodatabase that stores information about a relationship between two feature classes, between a feature class and a nonspatial table, or between two nonspatial tables. Both participants in a relationship class must be stored in the same geodatabase.” *

“In addition to selecting records in one table and seeing related records in the other, with a relationship class you can set rules and properties that control what happens when data in either table is edited, as well as ensure that only valid edits are made. You can set up a relationship class so that editing a record in one table automatically updates related records in the other table.” *

Relationship classes have a cardinality which is used to specify the number of objects in the origin class that can relate to a number of objects in the destination class. A relationship class can have one of three cardinalities:

• One-to-one
• One-to-many
• Many-to-many

No surprises there; we are following a relational data model. Cardinality can be set using the relationship cardinality constants provided by the ESRI API. Note that once a relationship class is created, the cardinality parameter cannot be altered. If you need to change the cardinality the relationship class must be deleted and recreated.
In a relationship one class will act as the origin and another as the destination. Different behaviour is associated with the origin and destination classes so it is important to define them correctly.
In code, relationships are expressed as instances of classes that implement the IRelationshipClass interface.
Note that relationships can have additional attributes (this is like adding extra columns to a link table to store data specific to an instance of the relationship). See The mythical ‘attributed relationship’ in ArcGIS for more details.

Simple relationships

In a simple relationship, related objects can exist independently of each other. The cascade behaviour is restricted; when deleting an origin object the key field value for the matching destination object is set to null. Deleting a destination object has no effect on the origin object.

Composite relationships

In a composite relationship, the destination objects are dependent on the lifetime of the origin objects. Deletes are cascaded from an origin object to all of the related destination objects.
The IRelationshipClass interface has an IsComposite parameter; a Boolean. Setting it to true indicates the relationship will be composite and setting it to false indicates that the relationship will be simple.

Relates

A relate is distinct from a relationship and is a mechanism for defining a relationship between two datasets based on a key. In other words this very much like an RDBMS foreign-key relationship (where one table has a foreign-key column that references the primary key of another table). So, a relate can be used to represent one-to-one and one-to-many relationships.

Joins

Although regarded as a separate construct in ArcGIS the join is really just what you’d expect a join to be in an RDBMS:

“Joining datasets in ArcGIS will append attributes from one table onto the other based on a field common to both. When an attribute join is performed the data is dynamically joined together, meaning nothing is actually written to disk.” ***

 

References

* Relates vs. Relationship Classes
** How to create relationship classes in the geodatabase
*** Modeling Our World, Michael Zeiler, ISBN 978-1-58948-278-4

Read More

If you listen to the .Net Rocks! podcast you may have heard the episode where Udi Dahan Clarifies CQRS. CQRS? What’s that all about then?
Health warning: I’m learning here. Errors and misconceptions probable. Jump to References below to go to more authoritative resources.
It looks like CQRS started with Bertrand Meyer as part of his work on the Eiffel programming language. At that time Meyer referred to the principle as Command-Query Separation (CQS). That principle states:

“…that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.” - Wikipedia

The implications of this principle are that if you have a return value you cannot mutate state. It also implies that if you mutate state your return type must be void.
CQRS extends CQS by effectively mandating that when we interact with data stores objects are assigned to one of two ‘types’: Commands and Queries. This division of responsibility extends into the rest of the architecture. You may have separate services dedicated to either commands (e.g. create, update and delete operations) or queries (read-only operations). It can even extend to the level of the data store – you may choose to have separate stores for read-only queries and for commands.
Why is this separation important? Well, it recognises that the two sides have very different requirements:

	Command	Query
Data Store	Store normalised data for transactional updates etc.	Store denormalised data for fast and convenient querying (e.g. minimise the number of joins required).
Scalability	Scalability may be less important for commands. For example many web systems are skewed towards more frequent read-only operations.	Scalability may be very important, especially in web systems. We may want to use caching here.

CQRS recognises that rather than having one unified system where create, read, update and delete operations are treated as being the same it may be better to have two complimentary systems working side by side: one for read-only query operations and another for command operations. The following diagram is somewhat over-simplified but…

Features of the Command side

• Our ‘data access layer’ for command operations becomes behavioural as opposed to data-centric.
• Our data transfer objects don’t need to expose internal state – we create a DTO and fire it off with a command.
• We don’t need to process commands immediately – they can be queued.
• We might not even require an ‘always on’ connection to the data store.
• We might use events to manage interaction between components in the command system.

Features of the Query side (the Thin Read Layer)

• We can create an object model that is optimised for display purposes (e.g. view models).
• We can create a separate data store that is optimised to meet the needs of the display object model (e.g. data can be denormalised to fit the requirements of specific views).
• We can optimise data access to prevent round trips to the data layer so that all the data required by a view is returned in one operation.
• We can optimise read-only queries in isolation from the requirements of update operations (this might be compromised in a non-CQRS system where, for example, an ORM is used for all data access operations).
• We can bypass direct interaction with the data store and use cached data (although we should be explicit about this when we do it – let the user know how fresh the data is).
• We can use different levels of caching for different parts of the application (perhaps one screen requires data to be fresher than another).

How do we keep the query data store in sync?

This is where events come in to the picture and I think I’ll leave that for another post!

References

• CQRS Introduction
• Udi Dahan – CQRS Clarified
• Rinat Abdullin - CQRS Starting Page

Read More

I was recently required to pick up some legacy code that included public fields along these lines:

public class SomeClass
{
    public int someInt;

    // ... snip ...
}

I have grown used to using auto-implemented properties under such circumstances:

public class SomeClass
{
    public int SomeInt { get; set; }

    // ... snip ...
}

To make matters worse different classes had different casing so sometimes public fields started with a capital and sometimes not (trivial but annoying). After my initial gasps of horror I got to thinking about the difference between exposing fields directly versus using properties. What really are the pros and cons?
MSDN describes properties in the following terms:

“A property is a member that provides a flexible mechanism to read, write, or compute the value of a private field. Properties can be used as if they are public data members, but they are actually special methods called accessors. This enables data to be accessed easily and still helps promote the safety and flexibility of methods.”

It turns out that Jeff Atwood is quite opinionated about the subject. Jeff acknowledges some arguments in favour of using properties over fields such as the following:

• Reflection works differently on fields than on properties. If you rely on reflection properties are a more natural fit.
• You can't databind against a field.
• Changing a field to a property is a breaking change requiring client code to be recompiled.

I also think that using a property signifies intent; it identifies that you intended the encapsulated field to be exposed outside the class. In effect by using a property you are declaring part of a contract, which is probably why you can declare properties in interfaces. This opinion seems to be confirmed by Jon Skeet:

“A property communicates the idea of "I will make a value available to you, or accept a value from you." It's not an implementation concept, it's an interface concept. A field, on the other hand, communicates the implementation - it says "this type represents a value in this very specific way". There's no encapsulation, it's the bare storage format. This is part of the reason fields aren't part of interfaces - they don't belong there, as they talk about how something is achieved rather than what is achieved.” - http://csharpindepth.com/Articles/Chapter8/PropertiesMatter.aspx

Properties also allow you to use combined access modifiers should you need to (note the private setter here):

public class SomeClass
{
    public int SomeInt { get; private set; }

    // ... snip ...
}

More verbose than simple public fields they may be, but I like properties.

Read More