Business object, wired object and calculator - which is better
I see this pattern over and over and wanted opinions:
Option 1: at the posting object and business object:
On a wired objec t is data that is serialized and sent back and forth across machines (client / server, etc.). This is a POCO object.
For example:
public class Order
{
public int Price;
public int Amount;
}
Business Objects is another class that usually has some or all of the properties as objects on a wired object, as well as some calculated fields. It usually uses composition on top of an object "on the wire".
public class OrderBusinessObject
{
private Order _order;
public OrderBusinessObject(Order o)
{
_order = o;
}
public int Price {return _order.Price;}
public int Amount{return _order.Amount;}
public int Total{return _order.Price * _order.Amount;}
}
Option 2: on wired object and business object using conversion:
This will be the same on the wired object as in example 1, but the business object will use translations instead of using composition:
public class OrderTranslator
{
public OrderBusinessObject Translate(Order o)
{
OrderBusinessObject bo = new OrderBusinessObject();
bo.Amount = o.Amount;
bo.Price = o.Price;
return bo;
}
}
public class OrderBusinessObject
{
private int _price;
private int _amount;
public int Price {return _price;}
public int Amount{return _amount;}
public int Total{return _price * _amount;}
}
Option 3: don't have a business object at all and do all your calculations in a separate calculator class. NOTE: consumers receive wired object and calculator
public class Consumer
{
public void ShowTotal(Order o)
{
Calculator calc = new Calculator();
double total = calc.ShowTotal(o);
}
}
I wanted to get people's opinion if there is a best practice or sample here, or if it's just a matter of user preference
source to share
For enterprise systems, I prefer option 2. This method facilitates contract design in an SOA environment and allows your domain objects to remain independent of wired representations. This makes it easier to change contracts over time and allows domain and info contacts to change independently of each other. The translation code can be a bit of a pain, but you can use a tool like Automapper to speed it up.
However, you may not require this level of flexibility in every application.
To me option 3 would go against object-oriented and domain-based principles as it supplants behavior leading to an anemic region model. Option 1 is also a bit at odds with domain based design because your domain models will depend on data contracts when in fact it should be the other way around. In the central domain model, these domain objects must be independent.