Charlie’s First Code
In my weblog entry, The Simplicity of Casting, I discussed why I had decided to create a low-level business object that I could pass around the system, which would then be “cast up” to its full type by the consuming class. In Expert C# Business Objects, the lowest business object is named BusinessBase. Personally, I find the use of the word business a little misleading, in that it suggests the objects must have some business relevance. In some literature, I have seen business objects referred to as entities. I find this term much more agreeable, since an entity is just a “thing,” and what we refer to as a business object is really just a code-version of some thing. I decided then that the most basic business object in Charlie would be named an Entity.
I grabbed a piece of paper and drew a box and wrote the word Entity inside it. I looked at it and said to myself, “That’s great, but if you just want a low-level type to pass around, you could just use System.Object. So how is an Entity going to differ from an Object?” I realised that what I really meant was that an Entity would represent a “persistable business object”. That is, an Entity would be a business object that saves and loads its data from a database. With that in mind, I wrote the first lines of code for Charlie:
namespace Charlie.Framework.Business
{
// **********************************************************
// Entity Class
//
/// <summary>
/// An Entity is a persistable business object.
/// </summary>
//
// **********************************************************
public abstract class Entity
{
}
}The next decision was what identification system to use for these entities. I had two main choices. I could use a simple integer. Or, I could use a complex GUID (globally unique identifier). Yet agan applying the principle that simple is better than complicated, I chose to use a simple integer.
namespace Charlie.Framework.Business
{
// **********************************************************
// Entity Class
//
/// <summary>
/// An Entity is a persistable business object.
/// </summary>
//
// **********************************************************
public abstract class Entity
{
// **********************************************************
// Id Property
//
/// <summary>
/// Gets and sets the identifier of the Entity.
/// </summary>
//
// **********************************************************
public Int32 Id
{
get
{
return this.id;
}
set
{
this.id = value;
}
}
private Int32 id = -1;
}
}Already this presented a problem. The ID value of an Entity should not be changeable by any class that uses it. One way to solve this would be to make a separate SetId method, and make that method internal in scope. However, this would prevent a Plugin from ever being able to set the ID of the entities it saves and loads. The clever way to resolve this would be to use Reflection so that only certain classes can set the ID value of an Entity. “To hell with that idea,” was my considered reply. And yet again, using the principle that simple is better than complicated, I came up with a simple convention. If a property is meant to be “settable” by other classes, then it will have a set accessor in that property:
public String Example
{
get
{
return this.example;
}
set
{
this.example = value;
}
}
private String example;If a property is not meant to be “settable” by other classes, it will not have a set accessor, but will instead have a separate SetWhatever method:
public String Example
{
get
{
return this.example;
}
}
private String example;
public void SetExample(String example)
{
this.example = example;
}Even if the scope of the property and its Set method were the same, as above, the convention conveys the message that the SetWhatever method is not meant to be used by the consuming classes. That is, it conveys the intention that the Example property is meant to be read-only, even if the SetExample method does happen to be available.
Having made that decision, I changed my Entity class, and documented my decision:
namespace Charlie.Framework.Business
{
// **********************************************************
// Entity Class
//
/// <summary>
/// An Entity is a persistable business object.
/// </summary>
//
// **********************************************************
public abstract class Entity
{
// **********************************************************
// Id Property
//
/// <summary>
/// Gets the identifier of the Entity.
/// </summary>
//
// **********************************************************
public Int32 Id
{
get
{
return this.id;
}
}
private Int32 id = -1;
// **********************************************************
// SetId Method
//
/// <summary>
/// Sets the Id property of the current Entity.
/// </summary>
/// <param name="id">The ID value to which to set the Entity
// </param>
// <notes>
// While this method has the same scope (public) of the Id
// property, we'll use a separate method to set the Id, as
// the Id property is properly meant to be a read-only
// property from the point of view of all consuming code.
// While we could use reflection to "hide" this SetId method
// as private, that seems like needless complexity.
// </notes>
//
// **********************************************************
public void SetId(Int32 id)
{
this.id = id;
}
}
}I certainly don’t intend to document every single piece of code. But the Entity class represents Charlie’s first code. After months of research, Charlie was underway.
by Alister Jones | Next up: The Entity System →
----
Post a Comment