Be Careful with MemberWiseClone and Reference Fields and ICloneable

by jmorris 8. September 2009 21:01

A common scenario most programmers have faced is the need to clone a cached object, so that when the object is modified on a per request basis - the cached 'orginal' object is not modified. For example, imagine that you have an XML file on disk and an in-memory object that contains the contents of the file (for lists, etc.). If the cost associated with opening the file (IO) and serialaizing is contents into the in-memory object are great and the cost of actually creating a copy of the in-memory object are small, then cloning the objt per request request, modifying it and then discarding per request is the way to go.

However, one small gotcha exists with Object.MemberWiseClone: while it actually creates a brand new object, it copies the references of non-primitive fields from the original object to the new object! So if you are not expecting changes to those fields, you are in for a big surprise:


After cloning you would expect that the original and cloned object would be disticnt objects with distinct object graphs, but that is not the case. Note that the Template object implements ICloneable and that templates.CloneTemplate(...) gets the orginal object from a dictionary and then makes a copy of it by calling Template.Clone() which uses MemberwiseClone() to create a copy of itself and return it to the caller.

Note that the MSDN documentation itself describes this behavior with reference type fields and MemberwiseClone():

"The MemberwiseClone method creates a shallow copy by creating a new object, and then copying the nonstatic fields of the current object to the new object. If a field is a value type, a bit-by-bit copy of the field is performed. If a field is a reference type, the reference is copied but the referred object is not; therefore, the original object and its clone refer to the same object." - MSDN

The solution is not use MemberwiseClone in your ICloneable implementation, unless you specifically want this kind of behavior and I am guessing that most folks want a real copy and not a shallow copy in which the object graph of the member variables points to the original objects roots. For example, replace this:



        #region ICloneable Members


        object ICloneable.Clone()


            return MemberwiseClone();



        public Template Clone()


            return ((ICloneable)this).Clone() as Template;






With the something like the following:





Using the Repository Pattern with the Command and DataMapper Patterns

by jmorris 1. September 2009 22:00

This post nearly completes the API defined in my earlier posts on the DataMapper pattern and the Command Pattern that shows a solution for executing queries against a remote service and mapping the results to POCO objects. The Command pattern implementation gave us a means of creating client requests with various combinations of parameters and allowed the query to be executed against the remote service. The DataMapper allowed us explicitly map the results of the query as a response in the form of an XML stream (SOAP Body) to objects on the client via CLR Attributes. To succinctly complete the union between the data store, the mapping layer and the domain layer we use the Repository pattern: “A Repository mediates between the domain and data mapping layers…Client objects construct query specifications declaratively and submit them to the Repository for satisfaction.”  - Fowler []

From an [earlier post], here is the whole, anemic API (with the exception of the WCF client used to communicate with the service):

From the model above, it’s pretty simple: commands are built by the client and executed against the service (the data store in this case), results are then mapped to POCO objects via .NET attributes and a little reflection. The repository becomes an intermediary between domain model, mapping and data store; it manages creation of the command object (and some parameter aspects) and then facilitates the mapping of the result set, hiding much of the heavy lifting (so, to speak) from the client. The client then gets a nice, clean typed object to use complete with intellisense and compiler support; much better than DataSets or XPath and XML.

Depending upon the implementation, the Repository lends itself to a rather simple structure; most of the moving parts involve the objects that it uses internally. Here is the code for the abstract IRepository class:

public abstract class Repository<T> : IRepository<T> where T : IEntit
        protected Repository(IDataMapper<T> dataMapper, IContentCommand command)
            DataMapper = dataMapper;
            Command = command;

        #region IRepository<T> Members
        public virtual List<T> GetAll(IQueryRequest request)
            IQueryResponse response = Command.Execute(request);
            using (var reader = new XmlTextReader(new StringReader(response.Xml)))
                return DataMapper.MapAll(reader);
        public virtual T Get(IQueryRequest request)
            request.Start = 0; request.Limit = 1;
            IQueryResponse response = Command.Execute(request);
            using (var reader = new XmlTextReader(new StringReader(response.Xml)))
                return DataMapper.Map(reader);
        public T Get(IQueryRequest request, out int count)
            request.Start = 0; request.Limit = 1;

            IQueryResponse response = Command.Execute(request);
            count = response.ResultCount;
            using (var reader = new XmlTextReader(new StringReader(response.Xml)))
                return DataMapper.Map(reader);
        public List<T> GetAll(IQueryRequest request, out int count)
            IQueryResponse response = Command.Execute(request);
            count = response.ResultCount;
            using (var reader = new XmlTextReader(new StringReader(response.Xml)))
                return DataMapper.MapAll(reader);
        public Dictionary<string, List<IEntity>> GetAll(IBatchQueryRequest queries)
            var results = new Dictionary<string, List<IEntity>>();
            IBatchQueryResponse response = Command.Execute(queries);
            for (int i = 0; i < response.Responses.Count(); i++)
                IQueryRequest query = queries.Requests[i];
                using (var reader = new XmlTextReader(new StringReader(response.Responses[i].Xml)))
                    var mapped = DataMapper.MapAll(reader) as List<IEntity>;
                    results.Add(query.Name, mapped);
            return null;
        public IDataMapper<T> DataMapper { get; set; }
        public IContentCommand Command { get; set; }
        public bool EnableServiceLayerCaching { get; set; }

Classes that derive from this are equally minimal in that they just override the constructor with appropriate IDataMapper<T> and IContentCommand implementions and they are ready to go. Note that the design supports Dependency Injection (DI) , which facilitates unit testing by providing hooks in which faked or mocked objects can be passed in by passing a direct dependency upon the service layer. My original implementation used a pure file based XML version independent of the remote service.

Tags: , , , ,

The Spin, Oh My, the Spin...

by jmorris 26. August 2009 21:40

A non software related tale today. Lately I have been amazed about all the 'Green Shoots' stories spun out by the media regarding economic recovery. Driving into work I heard, "Stocks open strong on good news regarding a housing recovery"....what? Well, I checked Marketwatch to see what this "good news" was and saw the following article: "US Stocks Turn Positive After Upbeat Home Sales Data". Wow, home sales climbed 9.7% in july and up 8+% year over year? Year over year growth in this economy is definitluy something to get excited about. I then turned to comments section and found this whoopee of a comment:

"As other have said countless times, please do your due civic duty of accurately reporting the facts. There is no need for the added spin MW. I feel really sorry for the editor because the constant spin is in the articles while the truth is filled up in the comments section. While we all appreciate being given the opportunity to engage in discussion, it is sad when we have to hunt down the facts on our own time. We can handle the truth so please just report the stone cold facts and let us make our own judgments and interpretations. Welcome to reality.

U.S. Existing Home Sales Yr/Yr
$0 – $100,000 Up 38.8%
100,000 – $250,000 Up 8.7%
$250,000 – $500,000 Down 6.2%
$500,000 – $750,000 Down 8.9%
$750,000 – $1,000,000 Down 10.6%
$1,000,000 – $2,000,000 Down 23.3%
$2,000,000 + Down 32.4%

Source: National Association of Realtors"

Original comment is here.

And I thought, what's the real story here? Sales of bottom of the market are up, but the mid-high level is way down. Nothing real exciting here given the 8k government subsidy and the risk taking nature of first time buyers. A little more research gives a more realistic view of the current housing market: Existing Homes: WhatsReally Selling.

The media spin machine appears to be working overtime; to bad the millions of unemployed in this recession/depression aren't feeling so peachy.

Tags: , , , , ,

Use System.Web.HttpRuntime.Cache Instead of System.Web.Caching.Cache for Unit Testing

by jmorris 24. August 2009 21:41

I ran into an interesting problem today while unit testing some code that depended upon System.Web.Cache where the Cache object itself was instantiated, but the internal dictionary was not. What happens is you end up getting null reference exceptions when you try add, remove, etc. anything from the Cache while unit testing. For example:


Kinda dififcult to spot what the issue is since it looks like the error is caused by the "PageTemplateKey" not matching on a cached item, but that's not the behavior of System.Web.Caching.Cache. When an item does not exist, null is what else could be causing this? The "'ContentFactory.Cache.Count' threw and exception" is the dead give away. The internal cache object was not being created in a non server environment.

For my unit tests I am using the Moq framework and mocking the major players of the ASP.NET HTTP stack. Notice that when I perform the setup on the mockContext object below I am setting the return value to be a new Cache(), this is where I am running into the issues described above.

So what to do now? There are at the least to ways to work around this issue: 1) create a mock cache wrapper or 2) use System.Web.HttpRuntime.Cache as a replacement. Opting for simplicity, I switched out the code on my MakeMockContext method to use System.Web.HttpRuntime.Cache and viola, problem solved:

This worked like a charm:


The reason why this works is that System.Web.Cache uses CacheInternal, which you guessed it, is set by an internal setter, called SetInternalCache. HttpRuntime directly makes the call to create CacheInternal when you access the HttpRuntime.Cache property.

Tags: , , , ,

Implementing the Command Pattern

by jmorris 19. August 2009 22:38

Command Pattern Background

One of the most ubiquitous software patterns in existence is the Command Pattern:  “Encapsulate a request as an object, thereby allowing for the parameterization of clients with different requests, queue or log requests, and support undoable operations” – GOF. It is generally used in situations where the all of the information necessary for a future call can be ‘built up” sequentially and finally executed at a point in time in the future – i.e. each action is state-full.

A common scenario is an object used to build up a database request taking in several different parameters such as the database name and location, the stored procedure name, any data that needs to be passed to the stored procedure and possibly a transaction object. Once the command has been constructed and all required parts are defined, it is executed, which delegates an action to call the stored procedure on the database and return a result set or perform some operation on an object, with the provided parameters. In the C# world, we are talking about System.Data.DbCommand and its concrete classes such as System.Data.SqlClient.SqlCommand or any other database specific implementation of DbCommand (Oracle, MySql, etc.).

Here is the basic UML diagram of the Command Pattern:

The Command Pattern typically utilizes the following actors:
  1. Client – creates the command object providing the relevant information (parameters) needed to fulfill its obligations
  2. Invoker – initiates the action on the command so that it’s obligations are fulfilled, making the decision of which of the commands actions should be called
  3. Receiver – performs the command object’s obligations, whatever they might be – i.e. makes database call or some other action

The Command Pattern Implemented

The scenario is this: a service exists which takes as input a series of inputs (a query) and returns as output, the results of those inputs as an xml stream of attributes and values. Caching at the service level and several operations are also supported: filtering, sorting, paging, etc.

Each request varies by parameters and is encapsulated as a query object defined by the client. This query object is simply a data structure that contains the fields accepted optionally be the service. The query object is executed by a command object created by the client, who delegates control to the receiver encapsulated by it’s invoking one of its action methods.

The following diagram illustrates the implementation:



The Command implementation is very simple. It contains an ICommandReceiver reference and IQueryRequest reference which stores a reference to the current query being executed. The command delegates control to the receiver, which performs its work and returns back an IQueryResponse object containing the results of the query.


The ContentReceiver class implements ICommandReceiver interface and simply makes the call to the remote service via a WCF client. This happens to be a very simplistic implementation in that much of the heavy lifting (i.e. caching, query generation, etc.) occurs in the service. In this case, we are simply translating a client query into a SOAP request to access the services resources.

The client uses an IQueryRequest object to build up a set of parameters which are consumed by the service endpoint via the command object. The results are returned to the client with an IQueryResponse object. How the results are used is dependent upon the client.

Finally, a simple unit test illustrating the usage:

Tags: , , , , ,

DataMapper Pattern Implementation with XML and Attributes

by jmorris 21. July 2009 22:17

The DataMapper Pattern is a well documented and defined pattern for abstracting away an object’s storage from its in-memory representation. For the most part the pattern explicitly defines the domain of the pattern to be relational databases and object’s that map to there schema, however the pattern is adaptable to non-relational data-stores as well. In fact to applicable to any situation where the need to map records (related data units) to in memory objects; regardless of structure or underlying store.

Imagine, for instance, a service that is a façade for a complex matrix of unstructured key value pairs and a protocol for clients to query the service for tuples. For example:

  • For the make ‘honda’, give me all ‘years’ 
  • For the article ‘2311’, give me ‘title’, ‘description’, ‘author’, ‘publication_date’

This is not too much different from any relational database model, with the exception that there is no direct joining occurring to return back columns that occur in different tables and relate them to the input set. It’s basically just a giant hash-map of name/values pairs with an undefined structure…i.e. there is no way to directly map it to a domain model; what you supply as inputs, defines the structure of your output.

That’s where the DataMapper Pattern comes into play. According to Fowler, the DataMapper is a “a layer of Mappers that move data between object and a database while keeping them independent of each other and mapper itself”. The core motivation behind the pattern is separation of concerns; an abstraction between the data, the store, and entity objects themselves. By using a DataMapper we can associate the name/value pair scenario described above with our domain objects, providing structure to our model. This is important because we go from an untyped hash-map model to tangible objects (POCO) that are typed, thus allowing us the benefits of developer friendly features of our IDE, such as ‘intellisense’ and compile time type safety.

Implemented within an API, you get something that looks like the following:

Think of it as a minimalistic ORM. In this case such concerns as caching and transactions are the responsibility of the underlying data-store service. As a consumer we are only concerned with making a request for data, getting a result set, and mapping it to an entity or domain object. In the diagram above, there are actually three different patterns working to create the whole: the command pattern, the repository pattern, and the data mapper pattern. All three comprise the entire API.

A Simple DataMapper Implementation:
This implementation of a DataMapper really does just three things: a) it reads through an XML stream, b) it maps to the values of specific XML attributes to an associated property, and c) packages the results into either a collection or a single object of the Type provided defined in the generic argument:

Map maps a single result to a single object. MapAll maps multiple results to a list of objects, and Read is a private method that extracts all key value pairs (XML attributes and there associative values) to a dictionary.

All Read does is extract out the XML attribute names and there associative data and store them in a dictionary. The dictionary is then used by the Map and MapAll methods along with a System.Attribute class to map the values directly to the correct properties:

In the code snippet above, after the Read method has extracted the data for mapping we loop over each of the objects properties looking for a FieldMappingAttribute on each of the properties we have flagged for mapping. If a match is found the relevant data is mapped directly to the object’s property and then the object is returned.


MapAll does essentially the same as Map, but assumes that the stream contains more than one object definition and then returns the resulting collection.

A couple of things to note here, the code a) needs a little refactoring to improve performance and extensibility, b) we are assuming a relatively flat xml file streamed here, no nesting of elements for example and c) we are only supporting properties of the Type System.String . The simplicity is purposeful…when I need it I’ll add it.

One last thing to discuss is implementation of FieldMappingAttribute and its usage. FieldMappingAttribute is a simple class deriving from System.Attribute that allows us to decorate properties on our entity classes with attributes that define our mapping schema:

The usage is pretty simple and should be familiar to most .NET developers:


Tags: , , , ,

WCF and Large Message Bodies

by jmorris 22. June 2009 16:39

I have been running into some situations WCF barfs on calls where the message body is very large:

"The maximum string content length quota (8192) has been exceeded while reading XML data. This quota may be increased by changing the MaxStringContentLength property on the XmlDictionaryReaderQuotas object used when creating the XML reader. Line 3, position 9381."

Took a little poking around to see what exactly was going wrong here, but a couple of posts got me going in the right direction. In fact, this is a real excellent exception message in that it tells me exactly what I need to do to resolve the issue: increase the MaxStringContentLength property on the XmlDictionaryReadersQuotas object that the BasicHttpBinding class is using. 

According to MSDN the MaxStringContentLength property:

 "Gets or sets the maximum size for a message that can be received on a channel configured with this binding."

The purpose of this restriction being the possiblity of DoS attacks on a publicaly exposed service caused by arbitrarily large messages. Since I am using TransferMode.Buffered, the message size is bound by the size of the MaxReceivedMessageSize by default.

This is the end result:

Tags: , , ,

XSLT Transformation Extension for XDocument

by jmorris 15. June 2009 22:49

I needed to update a utilities class I have been using to support XDocument (not just XmlDocuments) when I hit upon creating an extension method instead of the typical static utility class/method approach. Extension methods are a simple and powerful means of adding behavior to existing classes without breaking encapsulation. I was initially skeptical of the idea, but they have turned out to be rather nice and syntically better than static utilities classes.

The XDocument class is key part of the LINQ to XML API released with .NET Framework 3.5. Essentially it's a 'next' generation replacement for the XmlDocument class with added functionality for easily modifying in-memory Xml documents. Overall I prefer XDocument over XmlDocumentfor various reasons, but learning a new API can be a bit frustrating; it takes time to build a knowledge base of all of the 'gotchas' and 'hacks' ;)

Anyways, here is the final result:

Note that by convention I named the class after the class I was extending and added the 'Extensions' post fix. This makes things a little easier to manage. Here is the usage:


Tags: , , , , ,

Don't Use "Add Service Reference" Take 2: WCF Services The Right Way

by jmorris 28. May 2009 20:35
[No text]


I Broke Resharper! Or was it TypeMock?

by jmorris 15. May 2009 22:56

I was trying to test a IEqualityComparer implementation today, when Resharper kept crashing:


I tried rebooting, rebuilding everything. I finally clicked 'Debug' and waited...nothing happened after a few minutes, so I tried re-installing Resharper to no avail. By this time I was bruning through  my day, running out of time (deadlines, blah).

I clicked 'Debug' again and once again nothing happened....for awhile. I got up and ran a few 'errands' and came back an viola, I found my problem:


It was just a StackOverFlowException caused by my poor implementation of IEqualityComparer. Once I saw this I knew immediatly what was going on and how to resolve it. Of course, Resharper stopped crashing after I fixed the bug.

The big issue was why Resharper didn't handle this and just display the stacktrace as usual. It might be related to the fact that the exception was generated in TypeMock.dll, AFAIK I was not using TypeMock for this Unit test and there are no references to it in my project...weird

Tags: , ,

Jeff Morris

Tag cloud

Month List

Page List