Back to Part 2

Review Of Progress So Far

So, to date we have created an interface for our ShapeFactory and any other shape factory to implement, an enumeration that represents all the available shapes we may wish to build, and a factory class that can build any of our two current shapes. The next step is to create a graphical user interface that will call the factory and receive a couple of shape objects for it's trouble.

The Client Gets What They Deserve

Next we need a client to display the shapes, so for simplicity we are going to create a small Windows Forms project called WindowsApplication and add it to the solution. The project will have a single form called Main (700x550) which will have a picture box (uxPictureBox) and a button, uxDrawButton.

We now need to add a handler for the Draw Button and declare a Bitmap and a Graphics object at the top of the class. In the form constructor we will initialise the bitmap to a new instance which will be the size of the PictureBox. We will then create the Graphics object from the Bitmap.

In the button handler method we will clear the graphics object to a white background.

          
            public partial class Main
: Form { privateBitmap _bitmap; privateGraphics _graphics; public Main()
{ InitializeComponent(); _bitmap =newBitmap(uxPictureBox.Width,
uxPictureBox.Height); _graphics =Graphics.FromImage(_bitmap);
uxPictureBox.Image = _bitmap;
} privatevoid uxDrawButton_Click(object sender,
EventArgs e) { _graphics.Clear(Color.White); } }
        

We now need a collection to hold our shapes, so we will declare a list of objects that implement IShape at the top of the class, and to do this we will need to provide a reference to the ShapeInterfaces project. At the same time add a reference to the Factories project and import the namespaces for both projects at the top of the form code.

          
            using System.Text; using System.Windows.Forms; using Playground.ShapeMaker.Factories; using Playground.ShapeMaker.ShapeInterfaces; namespace Playground.ShapeMaker.WindowsApplication
{ public partial class Main
: Form { privateBitmap _bitmap; privateGraphics _graphics; private List<IShape>
_shapes; public Main()
{
        

Next we need to add two method stubs that are void of return values, AddShapes() and DrawShapes(). Surprisingly, AddShapes() will take responsibility for adding new shapes to our list and DrawShapes() will draw those shapes. We will add a line to create an instance of our list in the constructor and below that we will place a call to the AddShapes() method. We will place a call in the button handler to the DrawShapes() method, below the line that clears the graphics to a white background. Follow this with a refresh of the PictureBox.

          
            public Main()
{ InitializeComponent(); _bitmap =new Bitmap(uxPictureBox.Width,
uxPictureBox.Height); _graphics = Graphics.FromImage(_bitmap);
uxPictureBox.Image = _bitmap;
_shapes =new List<IShape>();
AddShapes(); } ///
<summary>///
Handles the draw button pressed event.///
</summary>///
<param name="sender"></param>///
<param name="e"></param>privatevoid uxDrawButton_Click(object sender,
EventArgs e) { _graphics.Clear(Color.White); DrawShapes();

uxPictureBox.Refresh(); }
        

In the AddShapes() method we need to create a new instance of our ShapeFactory object. Then using the ShapeFactory object add two shapes, a circle and a rectangle to the list.

          
             ///
<summary>
            ///
Adds shapes to the list
            ///
</summary>
            private
            void AddShapes()
{ ShapeFactory shapeFactory =newShapeFactory();
_shapes.Add(shapeFactory.CreateShape(Shape.Circle));
_shapes.Add(shapeFactory.CreateShape(Shape.Rectangle));
}
        

Because we know that the shapes Implement the IShape interface we have a contract that says we can call the Draw() methods on any of these shapes. These objects will then take the responsibility for drawing them selves. So in the DrawShapes() method all we need to do is iterate through all the shapes in the list and call each shapes Draw() method.

          
             ///
<summary>
            ///
Draws the shapes in the list
            ///
</summary>
            private
            void DrawShapes()
{ foreach(IShape
shape in _shapes)
{ shape.Draw(); } }
        

And that would be it... apart from we haven't added any working code into the Draw() methods of each concrete object yet!

A Change In The Contract

Apart from the fact there is no code in the concrete objects to actually draw them selves, I have just noticed the need to be able to pass the Graphics object into each shape object, so we need to go back to the interfaces and change the signature for the Draw() method.

So if we take a look in the IShape interface we need to be able to pass in a Graphics object as a method parameter.

          
            public
            interface IShape
{ ///
<summary>///
Represents the center of the shape///
</summary> Point Center { get; set;} ///
<summary>///
The method used to draw the shape///
</summary>///
<param name="graphics">A reference to the Graphics object to draw the shape
on.</param>void Draw(Graphics
graphics); }
          
          
        

And while we are in this project I think we will take the opportunity to extend the CreateShape() method signature in the IShapeFactory interface, too. We are going to add a center point parameter; this will allow us to position the shape where we like.

          
            public
            interface IShapeFactory
{ ///
<summary>///
Use this method to create a shape.///
</summary>///
<param name="shape">Indicates the type of shape to be made.</param>///
<param name="center">Indicates the center point of the shape.</param>///
<returns>An object that implements the IShape interface.</returns>IShape CreateShape(Shape shape, Point center);
}
        

A quick build of the project will highlight where our change in interface has broken the contract between it and the objects that implement it so in the BaseShape object we need to add a Graphics parameter into the Draw() method. This will be the same in the Rectangle and the Circle class.

          
            public
            abstract
            void Draw(Graphics graphics);
        

In the ShapeFactory class we need to extend the CreateShape(), CreateCircle() and CreateRectangle() methods signatures to include the center point parameter. Then in the CreateShape() method we need to pass the center point parameter on to the worker method calls.

          
            ///
<returns>A shape object that implements IShape.</returns>
            public IShape
CreateShape(Shape shape, Point center) {
        

In the two worker methods, CreateCircle() and CreateRectangle() we will populate the object's Center property with the value from the center parameter passed in.

          
             ///
<summary>
            ///
This method creates a circle object.
            ///
</summary>
            ///
<returns>A shape object that implements ICircle.</returns>
            private
            ICircle CreateCircle(Point
center) { Circle circle =newCircle();
circle.Center = center;
circle.Diameter = 50; return (ICircle)circle;
} ///
<summary>///
This method creates a rectangle object.///
</summary>///
<returns>A shape object that implements IRectangle.</returns>privateIRectangle CreateRectangle(Point
center) { BusinessEntity.Rectangle rectangle =new BusinessEntity.Rectangle();
rectangle.Center = center;
rectangle.Size =new Size(400,
200); return (IRectangle)rectangle;
}
        

Then back in the form code we need to alter the calls to the ShapeFactoryCreateShape() methods to include a center position

          
             ///
<summary>
            ///
Adds shapes to the list
            ///
</summary>
            private
            void AddShapes()
{ ShapeFactory shapeFactory =newShapeFactory();
_shapes.Add(shapeFactory.CreateShape(Shape.Circle, newPoint(250,250)));
_shapes.Add(shapeFactory.CreateShape(Shape.Rectangle, newPoint(350,
200))); } ///
<summary>///
Draws the shapes in the list///
</summary>privatevoid DrawShapes()
{ foreach(IShape shape in _shapes)
{ shape.Draw(_graphics); } }
        

Back to the Drawing Board

So finally we can get back into the concrete shape classes and write the code that will draw the shape.

So let us look at the Circle's Draw() method first. We'll add the code to allow the Circle to draw it's self.

          
             ///
<summary>
            ///
Use this method to draw the shape
            ///
</summary>
            public
            override
            void Draw(Graphics
graphics) { Pen pen =new Pen(Color.DarkGray,
0); int left = (int)Center.X - (Diameter/2); int top = (int)Center.Y - (Diameter/2);
System.Drawing.Rectangle outlineRectangle =new System.Drawing.Rectangle(left,
top, Diameter, Diameter); graphics.DrawEllipse(pen, outlineRectangle); }
        

And the same for the Rectangle.

          
             ///
<summary>
            ///
Use this method to draw the shape
            ///
</summary>
            public
            override
            void Draw(Graphics
graphics) { Pen pen =new Pen(Color.Red,
0); int left = (int)Center.X - (Size.Width / 2); int top = (int)Center.Y - (Size.Height / 2);
System.Drawing.Rectangle outlineRectangle =new System.Drawing.Rectangle(left,
top, Size.Width, Size.Height); graphics.DrawRectangle(pen, outlineRectangle); }
        

Now we need to make sure we have set the start up project to be the windows application and we should be good to go!

Conclusions

Now I'm certain that the application architecture and the code may not be laid out to best practises, and I'm aware there are plenty of parts that could have been better thought out and implemented, but really I just wanted to get a simple factory based application down on paper, so to speak, to get it a little clearer in my mind.

If any of these articles have helped you or planted the seed of inquisitiveness in your mind to find out more about factories then that can only be a good thing. If there is anything I have done in this article that is quite clearly incorrect or bad practise, please feel free to leave a comment. Any constructive feed back is appreciated.

The next step will be to make the objects prinatable. But until then, have fun!

Part 1 | Part 2

Back to Part 1

Review Of Progress So Far

So far we have two concrete shape classes, Circle and Rectangle that derive from a base shape class. The base shape class implements the IShape interface and the concrete classes implement in turn the IShape interface as well as their respective shape interfaces. The next step is to create a factory class to create our shapes.

Working In The Factory

So, we need to add to the solution, another new class library project which we will call Factories. This will house our ShapeFactory class. The ShapeFactory class will be responsible for creating our shape objects. It will be able to create and return an object that implements the IShape interface. So far we have ensured that both our circle and rectangle inherently implement the IShape interface for two reasons. One, because they both derive from the BaseShape object and we know that implements IShape, and two, because they implement ICircle and IRectangle which in turn implements IShape, as well. (Maybe some one with a little more experience than I, could advise if this is an acceptable practise. -> I can't see why not!)

But before we create our ShapeFactory we have one more thing to do. Because we may want to use more than one factory in the future to create our shapes we are first going to create another interface, which will describe what a ShapeFactory need to create some shape objects. This will be the IShapeFactory interface, and we are going to add that for the sake of simplicity to our ShapeInterfaces project

          
            using System; namespace Playground.ShapeMaker.ShapeInterfaces
{ publicinterfaceIShapeFactory { ///
<summary>///
Use this method to create a shape.///
</summary>///
<returns>An object that implements the IShape interface.</returns>IShape CreateShape();
} }
        

As you can see we have determined that any factory that implements IShapeFactory will have to contain a method that returns an object implementing IShape. The problem is, how do we determine what sort of shape we want to get? Well even though we only have two shapes at the moment for future expansion we will need an enumeration to represent these. As enumeration is to be used in every class that implements IShapeFactory and will need to be a parameter in the CreateShape method, it seems logical to me to place the enumeration in the ShapeInterfaces project. If any one can advise whether this is good practise or not, please do! So, let us add the Shape enumeration.

          
            using System; namespace Playground.ShapeMaker.ShapeInterfaces
{ ///
<summary>///
Represents the types of shapes that can be made///
</summary>publicenumShape { ///
<summary>///
Indicates the shape is to be a circle///
</summary> Circle, ///
<summary>///
Indicates the shape is to be a rectangle///
</summary> Rectangle } }
        

publicinterfaceIShapeFactory { ///
<summary>///
Use this method to create a shape.///
</summary>///
<param name="shape">Indicates the type of shape to be made.</param>///
<returns>An object that implements the IShape interface.</returns>IShape CreateShape(Shape shape);
}

So it's back to the Factories project now to create the ShapeFactory class that will provide us with some shapes. To create some shapes we need to add a reference to both the BusinessEntity and the ShapeInterfaces projects into the Factories project. After adding our new ShapeFactory class into the Factories project we need to import the BusinessEntity and the ShapeInterfaces namespaces into the top of it. We now need to make the ShapeFactory class implement IShapeFactory.

using System; using Playground.ShapeMaker.BusinessEntity; using Playground.ShapeMaker.ShapeInterfaces; namespace Playground.ShapeMaker.Factories
{ publicclassShapeFactory :
IShapeFactory { #region IShapeFactory
Members publicIShape CreateShape(Shape shape)
{ thrownewException("The
method or operation is not implemented."); } #endregion }
}

We are now going to create a pair of private methods that will create our two shapes. Although these methods will create two concrete objects the methods will return not the objects but their interfaces. First though we will just create the method stubs. Then we will modify the CreateShape() method to call one or the other of these two methods depending upon the enumerated value passed in.

#region IShapeFactory
Members ///
<summary>///
Creates a shape and returns it.///
</summary>///
<param name="shape">Indicates the shape to create.</param>///
<returns>A shape object that implements IShape.</returns>publicIShape CreateShape(Shape shape)
{ IShape createdShape =null; switch (shape)
{ caseShape.Circle:
createdShape = CreateCircle(); break; caseShape.Rectangle:
createdShape = CreateRectangle(); break; default: thrownew Exception("Unknown
shape encountered in CreateShape() method."); } return createdShape;
} #endregion///
<summary>///
This method creates a circle object.///
</summary>///
<returns>A shape object that implements ICircle.</returns>privateICircle CreateCircle()
{ } ///
<summary>///
This method creates a rectangle object.///
</summary>///
<returns>A shape object that implements IRectangle.</returns>privateIRectangle CreateRectangle()
{ }

We have used switch / case to select which method will create our shape object. Notice that we use the default case to throw an exception if we encounter a shape that we haven't catered for. This is in case at any time the shape enumeration is extended to provide more shapes. Notice also that although the CreateShape() method returns an object that implements IShape, the two worker methods return ICircle and IRectangle. This works because both ICircle and IRectangle both implement the IShape interface, and that is what CreateShape() will return.

Anyway let us crack on and 'flesh out' the CreateCircle() worker method! Because our shapes using the System.Drawing namespace, our factory that is going to create these will need to also. So we need to add a reference to and import that namespace for the ShapeFactory. (Incidentally have you noticed the more you look at the word "circle" the more wrong it looks!)

 ///
<summary>///
This method creates a circle object.///
</summary>///
<returns>A shape object that implements ICircle.</returns>privateICircle CreateCircle()
{ Circle circle =newCircle();
circle.Center =newPoint(250,250);
circle.Diameter = 50; return (ICircle)circle;
}

Now I would normally use constructor in my code, but this example isn't to show best practise of constructing objects, so I am going to construct my objects using the properties today. You will probably also notice that I am casting the newly constructed Circle object to the type of ICircle before returning it. You don't need to do this but I believe it is good practise. (Can any one confirm this please?)

At this point I have just realised an error with choosing a rectangle for a shape, due to a conflict with the System.Drawing.Rectangle object. Well we could change the shape to a square or a triangle.... but we have got this far, so I am going to stick with it. It will however mean there will be some ugly code with the BusinessEntity namespace forced in here and there!!!

 ///
<summary>///
This method creates a rectangle object.///
</summary>///
<returns>A shape object that implements IRectangle.</returns>privateIRectangle CreateRectangle()
{ BusinessEntity.Rectangle rectangle =new BusinessEntity.Rectangle();
rectangle.Center =new Point(300,
300); rectangle.Size =new Size(400,
200); return (IRectangle)rectangle;
}

Now that should be it for our ShapeFactory for the moment. If all has gone well for you then your project should build without errors.

To sum up we have created an interface for this and any other shape factory to implement, an enumeration that represents all the available shapes we may wish to build, and a factory class that can build any of our two current shapes. the next step is to create a graphical user interface that will call the factory and receive a couple of shape objects for it's trouble.

Part 3

Background

Recently I have been reading quite a bit about Factory Patterns and Inversion of Control (IOC). However like most principles that are new to me I often find them very hard to visualise at first, and even harder to put them into practise. So I am going to try a simple application using what I believe to be a Factory Pattern. The aim of the game will be to use a factory to produce shapes that will be drawn using .Net's GDI classes in a Windows form application.

This article assumes that the reader is already comfortable with the use of interfaces and inheritance in classes.

The files created in this article can be downloaded from here: 2008-04-11_ShapeMaker.zip (103.25 KB) 

Interfaces

The first thing I'm going to do is to create a Blank Solution, using Visual Studio 2005, which I am going to call ShapeMaker. To this solution I am going to add a New Project which will be a Visual C# Class Library which I am going to call ShapeInterfaces.

I'll close and delete the default Class1.cs class file before I proceed. I shall now add a new Interface called IShape and remove the two unused using statements. To the IShape interface I am going to add a System.Drawing.Point property called Center and import it's namespace after first adding a reference to the System.Drawing assembly. I shall then add a method that is void of a return type and call it Draw().

          
            using System; using System.Drawing; namespace Playground.ShapeMaker.ShapeInterfaces
{ publicinterface IShape
{ ///
<summary>///
Represents the center of the shape///
</summary> Point Center { get; set;} ///
<summary>///
The method used to draw the shape///
</summary>void Draw();
} }
        

All shapes that I intend to create will implement this interface. The Center property will define the center point of the shape, and the Draw() method will allow any user interface to know that when it is required to draw the shape it can call this method and the shape will be responsible for drawing it self.

I'm now going to add two more interfaces which will both implement the IShape interface, the ICircle which will also have a integer Diameter property...

          
            using System; using System.Drawing; namespace Playground.ShapeMaker.ShapeInterfaces
{ publicinterface ICircle
: IShape { ///
<summary>///
Represents the diameter of the circle///
</summary>int Diameter
{ get; set;
} } }
        

...and the IRectangle which will have a Size property.

          
            using System; using System.Drawing; namespace Playground.ShapeMaker.ShapeInterfaces
{ publicinterface IRectangle
: IShape { ///
<summary>///
Represents the size of the rectangle///
</summary> Size Size { get; set;}
} }
        

Base Classes

I'm now going to add another class library project to the solution which will be my BusinessEntity layer, from which I will also delete the default Class1 class. To the BusinessEntity project I am going to add a folder called BaseClasses. I would probably normally use a separate project for my base classes but for clarity of this example I shall place them in this folder.

To the BaseClassses folder I am going to add a class that all my shape entities will inherit from. I shall call this BaseShape. As I intend for BaseShape to implement the interface IShape I need to add a reference to the ShapeInterfaces project from the BusinessEntity project, and then import the namespace into the BaseShape class.

          
            using System; using Playground.ShapeMaker.ShapeInterfaces; namespace Playground.ShapeMaker.BusinessEntity.BaseClasses
{ publicabstractclass BaseShape
: IShape { } }
        

We have declared the class as abstract as we do not want this class to be able to be constructed. It will just be used a s a base for other classes to derive (inherit) from. Right clicking on the interface name and selecting Implement Interface from the context menu...

... should inject the following code into the class.

          
            #region IShape
Members public System.Drawing.Point
Center { get { thrownew Exception("The
method or operation is not implemented."); } set { thrownew Exception("The
method or operation is not implemented."); } } publicvoid Draw()
{ thrownew Exception("The
method or operation is not implemented."); } #endregion
        

We will now need to add a reference to the System.Drawing assembly and import the name space before we can build or we will receive an error. The next task to do is to declare a private field, _center, which will hold our center point data and then we will modify the Center property to access that field. Then we will declare the draw method as abstract so it must be overridden by any derived class.

          
            private Point
_center; #region IShape
Members ///
<summary>///
Gets or sets the center point of the shape.///
</summary>public Point
Center { get { return _center;
} set {
_center = value;
} } ///
<summary>///
All inherited classes will contain this method.///
The method will be used to draw it's self.///
</summary>publicabstractvoid Draw(); #endregion
        

Derived classes

Next up is to create two shape classes that will derive from the base class. The first shape we will create will be a Circle. We will add it to the root of the BusinessEntity project, and make it both derive from the BaseShape class and implement the ICircle interface. To make this class derive correctly from the BaseShape class we will need to declare a Draw() method and mark it as an override.

          
            using System; using Playground.ShapeMaker.BusinessEntity.BaseClasses; using Playground.ShapeMaker.ShapeInterfaces; namespace Playground.ShapeMaker.BusinessEntity
{ publicclass Circle
: BaseShape, ICircle { #region ICircle
Members publicint Diameter
{ get { thrownew Exception("The
method or operation is not implemented."); } set { thrownew Exception("The
method or operation is not implemented."); } } #endregion///
<summary>///
Use this method to draw the shape///
</summary>publicoverridevoid Draw()
{ } } }
        

We can now create a private field _diameter and set the Diameter property to access it fully. The next shape we will add will be the Rectangle, which we will do in much the same way, except that we will create a field to hold the size data and access it from the Size property.

          
            using System; using System.Drawing; using Playground.ShapeMaker.BusinessEntity.BaseClasses; using Playground.ShapeMaker.ShapeInterfaces; namespace Playground.ShapeMaker.BusinessEntity
{ publicclass Rectangle
: BaseShape, IRectangle { privateSize _size; #region IRectangle
Members ///
<summary>///
Gets or sets the size of the rectangle.///
</summary>publicSize Size
{ get { return _size;
} set {
_size = value;
} } #endregion///
<summary>///
Use this method to draw the shape///
</summary>publicoverridevoid Draw()
{ } } }
        

Summing up so far...

So far we have two concrete shape classes, Circle and Rectangle that derive from a base shape class. The base shape class implements the IShape interface and the concrete classes implement in turn the IShape interface as well as their respective shape interfaces.

Part 2 will show the next step, which is to build a factory class which will be used to create and return our shape objects at runtime.

I'm sure most of us endeaver to keep the tightest scope possible for the members of classes we write. But I have a situation where I just can't seem to be able to keep the scope of members of my inherited class as tight as I would like.

What I am intending to create is a Job object that will inherit from a BaseJob object that will implement the IJob interface. While doing this I want to ensure the JobFactory member of the Job object is kept private and the Id member is public. Both of these members belong in the BaseJob object.

So I'll start with new assembly that will contain three interfaces; IJob, IIdentifyable and IJobFactory.

          
            public
            interface
            IJob : IIdentifyable { ///
<summary>///
Gets or sets a reference to the factory that created the IJob object.///
</summary>IJobFactory JobFactory { get; set;
} }
        

          
          
          
            
              
                ///
<summary>
                ///
Represents the signature for an object that is identifyable

              
            
          
          
            
              
                ///
</summary> public
              interface
              IIdentifyable { ///
<summary>///
Gets or sets a reference to the identity of the IJob object.///
</summary>int Id { get; set;
} }
          
        

          
            
            
            ///
<summary>
            ///
Represents the signature required for a job factory.
            ///
</summary>
            public
            interface
            IJobFactory { ///
<summary>///
Creates an object that implements the IJob interface.///
</summary>///
<returns>Returns an object that implements the IJob interface</returns>IJob Create(); ///
<summary>///
Saves the current job///
</summary>void Save(IJob job);
}
        

IJob has a member which will be used to hold a reference to an object (that implements the IJobFactory inteface) that created it. It will also have a Id member implemented through the IIdentifyable interface. IJobFactory has a method for returning a newly created object that implements the IJob interface and a method to save an object that implements the IJob interface. Both interfaces must be public as they need to be seen from outside the assembly. As far as I am aware you canot declare the scope of the methods in an interface so each will be of the same scope as the interface.

I now need to another new assembly which will contain a base class (BaseJob) for my Job object to inherit from. I create a reference to the interfaces assembly, and allow the BaseJob class will implement the IJob interface from it.

          
            ///
<summary>
            ///
The base class that all Job objects should inherit from.
            ///
</summary>
            public
            abstract
            class BaseJob
: IJob { privateint _id; privateIJobFactory _jobFactory; #region IIdentifyable
Members ///
<summary>///
Represents the identity of an Job///
</summary>publicint Id
{ get { return _id
; } set { _id = value;
} } #endregion#region IJob
Members ///
<summary>///
Gets or sets a reference to the factory that created the IJob object.///
</summary>publicIJobFactory JobFactory
{ get { return _jobFactory;
} set { _jobFactory = value;
} } #endregion }
        

Now, I would like to set the scope of the BaseJob's Id and Jobfactory members as protected, do they can only be seen by objects that inherit from the BaseJob object. However if I try and make the scope any tighter then VS advises me of an error when I try to build.

Error 1 'BaseJob' does not implement interface member 'IJob.JobFactory'. 'BaseJob.JobFactory' is either static, not public, or has the wrong return type.

So as far as I can see it has to stay public. Any way on to my Job object now. In a third assembly, which has a reference to both the base class assembly and the interfaces assembly,  I create the Job class.

          
            public
            class Job
: BaseJob { public Job(int id, IJobFactory jobFactory)
: base()
{ base.Id = id; base.JobFactory = jobFactory;
} }
        

The Job class has a contructor which allows me to pass in the identity and the JobFactory which is used to create it ( I hope to write an post / question on dependency injection next!). My problem is I don't intend the JobFactory property of the Job object to be visiable outside the class code, so ideally I would like to scope it as private. However it is an inherited member that already has a scope of public. I can quite clearly see the member like so...

          
            class TestClass
{ Job _job; public TestClass()
{ _job =newJob();
_job.JobFactory = ...;
} }
        

The only way I can see to hide the member is by overriding the JobFactory member to the Job object with the new modifier like so.

          
            private
            new IJobFactory
JobFactory { get { returnbase.JobFactory;
} }
        

Is this really the best way to go about this, or am I doing something fundementally wrong? Your comments appreciated!

Background

As part of an ongoing project where a light weight client application needs to communicate with a database via a webservice I have been trying to get my head around a the best way to encapsulate data within custom objects and pass it from the client 's GUI to the Web Service's Data Access layer without replicating too much code or having the the client hold a reference to the same assembly as the webservice.

The intention is for the client application to have 3 layers, the presentation layer, a Business Entity / Business Logic layer and an Webservice Adapter layer. The Webservice will have the WebService layer, it's own Business Entity / Business Logic layer and a Data Access layer.

Initial Thoughts

My initial thoughts were to create an assembly which would hold a set of interfaces that will describe the business entities that both parts of the application would use. For example the interface fot the job object would be:

          
            public
            interface IJob
{ int Id; string CreatedBy; DateTime CreatedOn;
. . DateTime LastAccessed; }
        

This would require that both pairs of business entity assemblies would need to have a reference to the assembly. My plan was then to return from the webservice's webmethods the interface rather than the object. For example.

          [WebMethod] public IJob
GetJobById(int id)
{ . . }
        

My plan was then bind the form controls to the properties of the interface but among a couple of minor flaws in my plan, there was one big one... It appears that you can not return an interface from a web service. I assume do to it not being serialisable. A little research later it appears that a better way would be to would be to use a shared base class for the business entities on both sides of the void, so to speak. So back to the drawing board slightly..

Second Thoughts

So now I'm thinking I need to create an abstract base class for the objects in the business entitiy assemblies in both the client and the webservice to inherit from. If I ensure the base classes implement the interfaces, then I can still bind my controls to the interfaces properties. So ignoring the various properties of the class I now have a bas class that implements the previosu

          
            protected
            abstract
            class BaseJob
: IJob { . . }
        

So now the Job class in each business entity layer will inherit from the BaseJob abstract class which implements the IJob interface.

          
            public
            class Job
: BaseJob { . . }
        

So this means that now rather than just having a reference to the assembly with the interfaces in for each business entity assembly I now have a reference to the base class assembly too. Is this really the way I want to go?

To be continued...