Skip to main content

Code refactoring - NULL check (Part 3)

Part 1
Part 2
Part 3
In my last two posts I wrote about “Null Object Pattern” in different scenarios. This post is related to this subject and we will discover how we can use this “pattern” when we are working with interfaces.
Let’s assume that we have the following interface and implementation of the interface:
public interface IFoo
  int A { get;set; }
  int B { get;set; }
  int C { get;set; }

public class Foo : IFoo
  public int A { get;set; }
  public int B { get;set; }
  public int C { get;set; }

In this case we would need a mechanism to implement a null object. We could create a static property to the Foo object that represents the null (default) value. This could be a solution but is not the best one.
Off topic: I really don’t like the NULL naming. I would prefer a name like “Default”.
What about creating a class that represents our null interface?
Creating a class that implement our interface that represent our null object will help us a lot when we need to check if the object represent the “null” object or an initialize object. Also, in this way we will not have our Foo class polluted with different fields/properties.
public class NullFoo : IFoo  
  private int _defaultA = 0;
  private int _defaultB = -1;
  private int _defaultC = -1000;
  public int A { get { return _defaultA } }
  public int B { get { return _defaultB } }
  public int C { get { return _defaultC } }
What we gain using this solution? We have a code that is clearer and easier to understand. On the other hand, we added complexity to our code. Also we still need to initialize the object with value and detect if an object represent the “null” object.
In conclusion even if this solution adds complexity to our code, the code will be easier to read and our intention is very clear to the reader.
Part 1
Part 2
Part 3


Popular posts from this blog

ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded

Today blog post will be started with the following error when running DB tests on the CI machine:
threw exception: System.InvalidOperationException: The Entity Framework provider type 'System.Data.Entity.SqlServer.SqlProviderServices, EntityFramework.SqlServer' registered in the application config file for the ADO.NET provider with invariant name 'System.Data.SqlClient' could not be loaded. Make sure that the assembly-qualified name is used and that the assembly is available to the running application. See for more information. at System.Data.Entity.Infrastructure.DependencyResolution.ProviderServicesFactory.GetInstance(String providerTypeName, String providerInvariantName) This error happened only on the Continuous Integration machine. On the devs machines, everything has fine. The classic problem – on my machine it’s working. The CI has the following configuration:

TeamCity.NET 4.51EF 6.0.2VS2013
It seems that there …

GET call of REST API that contains '/'-slash character in the value of a parameter

Let’s assume that we have the following scenario: I have a public HTTP endpoint and I need to post some content using GET command. One of the parameters contains special characters like “\” and “/”. If the endpoint is an ApiController than you may have problems if you encode the parameter using the http encoder.
using (var httpClient = new HttpClient()) { httpClient.BaseAddress = baseUrl; Task<HttpResponseMessage> response = httpClient.GetAsync(string.Format("api/foo/{0}", "qwert/qwerqwer"))); response.Wait(); response.Result.EnsureSuccessStatusCode(); } One possible solution would be to encode the query parameter using UrlTokenEncode method of HttpServerUtility class and GetBytes method ofUTF8. In this way you would get the array of bytes of the parameter and encode them as a url token.
The following code show to you how you could write the encode and decode methods.

Entity Framework (EF) TransactionScope vs Database.BeginTransaction

In today blog post we will talk a little about a new feature that is available on EF6+ related to Transactions.
Until now, when we had to use transaction we used ‘TransactionScope’. It works great and I would say that is something that is now in our blood.
using (var scope = new TransactionScope(TransactionScopeOption.Required)) { using (SqlConnection conn = new SqlConnection("...")) { conn.Open(); SqlCommand sqlCommand = new SqlCommand(); sqlCommand.Connection = conn; sqlCommand.CommandText = ... sqlCommand.ExecuteNonQuery(); ... } scope.Complete(); } Starting with EF6.0 we have a new way to work with transactions. The new approach is based on Database.BeginTransaction(), Database.Rollback(), Database.Commit(). Yes, no more TransactionScope.
In the followi…