Object Oriented Data Marshalling

Adam Jasper

I have developed an application architecture and we are all using it here at my company. Problem is, some of the guys are having problems getting their heads around it and now I am having doubts myself. I will try and explain without rambling on too much. What I have is a web service with methods similar to the following for marshalling data back and forth between the client and server: public SimpleBusinessEntity Save(SimpleBusinessEntity entity); All classes in the application derive from SimpleBusinessEntity. The only field that SimpleBusinessEntity contains is the EntityType field which is an enum value to determine its type i.e. Tariff, Contract Using the base entity class means I don't have to create web methods for each type of entity i.e. SaveTariff, SaveContract etc. When the client sends an entity to a web method, I check the EntityType property of the SimpleBusinessEntity and then call the appropriate workflow class which will process that type of business entity i.e. TariffWorkflow. So the server-side TariffWorkflow class would have a method such as: public TariffEntity Save(TariffEntity entity); Do people on this forum use similar techniques? I have developed a number of applications using this technique and I think it works well. It is easy to maintain and enhance. The problem I have is explaining it to others and getting them to understand the concept. These are experienced people. Have I made it too complicated? Thanks in advance, Adam

R Giskard Reventlov

Based upon your description appears fairly straightforward. What is it that they don't understand? Are they VB developers? :-)

me, me, me

Adam Jasper

Thanks for your response. Yes, we were all VB developers here. ;) I moved over to c# about five or six years ago. Some of the others haven't been able to do this, so their c# exposure has been in fits and starts. Maybe I am just no good at explaining it. :-D Adam

led mike

Adam Jasper wrote:

These are experienced people.

[rhetorical since the VB cat is out of the bag] Experienced in what, breathing? [/rhetorical]

Adam Jasper wrote:

Have I made it too complicated?

No. But it's not object oriented because this:

Adam Jasper wrote:

The only field that SimpleBusinessEntity contains is the EntityType field which is an enum value to determine its type i.e. Tariff, Contract

is not object oriented. However since your peers can't even understand what you are doing now they sure as hell would be totally lost if you implemented an object oriented solution so I guess that's not a consideration.

led mike

Adam Jasper

led mike wrote:

is not object oriented. However since your peers can't even understand what you are doing now they sure as hell would be totally lost if you implemented an object oriented solution so I guess that's not a consideration.

Sorry led mike, you will have to explain that one to me, how is it not object oriented? SimpleBusinessEntity is an abstract class that has one property and a few abstract methods. All other classes derive from SimpleBusinessEntity because essentially every other business entity can be considered a simple business entity. Some processes only work with simple business entities using the EntityType property and the methods. How is that not object oriented? I am interested to know your thoughts. Regards, Adam

R Giskard Reventlov

led mike wrote:

Experienced in what, breathing?

:laugh:

led mike wrote:

is not object oriented

To be fair he never said it was: he really only asked if it was understandable or too complicated, which, of course , for VB 'programmers', it is.

me, me, me

led mike

digital man wrote:

To be fair he never said it was:

The what does that subject line say? :confused:

led mike

led mike

Adam Jasper wrote:

Sorry led mike, you will have to explain that one to me, how is it not object oriented?

The answer to that question is to explain Object Oriented Design. Obviously I can't do that since entire books and web sites have been dedicated to that very explanation and still mostly fall short of giving any individual that knowledge. Perhaps it's because one person cannot give the understanding of OOD to another person. Perhaps understanding OOD must be arrived at by taking a journey down that path. Wow that was bunch of fluff eh? A short statement I might make to even point you in a direction is that what you describe might be referred to as "using objects" as opposed to "object oriented". I know that probably doesn't help, but like I said, short of writing a book. This is kind of weird since I just posted this[^] like 15 minutes ago Also Web Services do not tend to be Object Oriented because of their remote nature they are generally a request-response oriented interface.

led mike

Adam Jasper

I too have read many books, articles etc about object oriented programming. Nothing I mentioned in my original post broke any of the rules as far as I know. I can only assume you are talking about my use of the enumeration constant. I have read some articles that suggest they should no be used. However, since I never cast to another type I don't see the problem. I do agree that it is very difficult to pass on OO knowledge. I have been doing it for about 12 years now and no matter how many times you tell them what you are going to tell them, tell them, then tell them what you told them you still get asked the same questions. I am only using the web service to marshall data back and forth between client and server. Basically, when the UI calls the tariff.Save method, the Tariff business object converts itself to a Tariff business entity and asks the web service to save the business entity. This is as you suggest, a request/response oriented interface. Thanks for your time, Adam

led mike

Adam Jasper wrote:

I have read some articles that suggest they should no be used.

Well that's not what I said. It's not object oriented is what I said, that doesn't mean you shouldn't do it, it only means you should understand the ramifications of a non object oriented solution in that particular context and make an informed decision. One example of what a non object oriented solution means is, you will have to change existing code to extend functionality rather than implement a new class that encapsulates the new functionality. In your case for example you have to change the enum and likely code that uses the enum, this is likely what you have read others saying you should not do and can also be referred to as Technical Debt[^]. All that said, there are Software Design Patterns that can be used to avoid the enum approach you have implemented. Utilizing these patterns normally allows you to implement a OO design where introducing a new class is all that is required to extend functionality. No existing code is changed. The historically proven benefit of that is an increase in quality. This means reduced ripple effect and less chance of errors that result in system failure. The larger and therefore more complex a system is the greater the odds become of resultant errors due to Technical Debt. Furthermore studies have proven that the cost to the company of dealing with errors can be 100 fold greater than doing the upfront design and development to eliminate the Technical Debt. No doubt since you have been doing this for 12 years and read all sorts of stuff you already know all that. :)

led mike

R Giskard Reventlov

Um, yes I suppose one could read it that way: interpretation is everything. I ignored the heading and concentrated on the question: my mistake.

me, me, me

Adam Jasper

Yes, enums do violate the open/closed principle as they cannot be extended. However, as long as you only add new values to the end of the enum and do not change any existing values I think it is generally considered to be acceptable to use enums in OOD. I have yet to see a design pattern that solves this problem completely, what design patterns are you referring to? You are correct to say it is a design decision. I do make some rules that I adhere to myself regarding enums i.e. I never cast to another type to iterate through the values because this could break existing code if I add a new value to the end. I do need to modify classes to check for a new enum value, however, I only add code, I don't change existing code. Therefore, if I cannot say my design is object oriented then so be it. It is a lot simpler than any of the other alternatives I have seen. :) Thanks for your comments, Adam

Leslie Sanford

You have something like this?

public SimpleBusinessEntity Save(SimpleBusinessEntity entity)
{
switch(entity.EntityType)
{
case EntityType.TariffEntity:
tariffWorkflow.Save((TariffEntity)entity);
break;

case EntityType.Contract:
    contractWorkflow.Save((Contract)entity);
    break;

default:
    Debug.Fail();
    break;
}

}

Is this more or less correct? In an object oriented approach, you use polymorphism to do the dispatching. This means creating several Save methods, one for each type:

public void Save(TariffEntity entity)
{
}

public void Save(ContractEntity entity)
{
}

The general consensous is that it's easier to maintain the latter approach than the long switch statements. This is especially true if you have several switch statements duplicate switch statements throughout your code. Having said this, there are times where switch statements are appropriate. At the boundary of an application (which may apply here) you may find yourself having to switch on data in order to transform it into a form the rest of the application can use. For one thing, C# doesn't support double dispatching, so having several Save methods like the above may not work. At any rate, hope something in the above provides some insight.

Adam Jasper

Hi Leslie, Thanks for your comments, much appreciated. I don't actually need to use a switch statement in this case. I try and avoid it where possible. Really the only time I use a switch statement is in a factory class, I can't think of a way around it in some instances. I'll explain how I have avoided a case statement with code snippets (this is off the top of my head as I don't have the actual code to hand at the moment): private Dictionary<BusinessEntityType, IEntityWorkflow> _workflows; public PersistenceWorkflow() { _workflows = new Dictionary<BusinessEntityType, IEntityWorkflow>(); InitialiseEntityWorkflows(); } protected virtual void InitialiseEntityWorkflows() { _workflows.Add(BusinessEntityType.Tariff, new TariffWorkflow()); _workflows.Add(BusinessEntityType.Contract, new ContractWorkflow()); } then, the actual save method is something like this: public SimpleBusinessEntity Save(SimpleBusinessEntity entity) { IEntityWorkflow workflow = _workflows[entity.EntityType]; return workflow.Save(entity); } The implementation of the IEntityWorkflow.Save method in TariffWorkflow would cast to the relevant type e.g. TariffEntity. I know the one disadvantage of this design is that I am instantiating more objects than I am going to use, however, I think it is a small price to pay for a very extensible design and I will never have that many entity workflows. Regards, Adam

Leslie Sanford

Ah, I see. You've created a table with the enumeration values acting as indexes into the table; it's a dispatch table. That's ok, but what you're doing is recreating the virtual table that C# gives you for free using polymorphism. I'm not advocating that you change this; if it's working for you, stick with it. Just be aware that when using virtual methods, the language creates the table for you internally. Having said that, there have been times when I've used similar approaches, usually to make up for C#'s lack of double dispatching (and I don't feel like implementing Visitor).

Adam Jasper

Hi Leslie, Thanks again for your comments. I did originally want to use the Visitor pattern but I will extend the application with more elements and I think that is where the Visitor pattern falls down. I did look at another pattern, a quick search on Google tells me it was called Acyclic Visitor, however, it didn't tick all the boxes either. Regards, Adam