I've read numerous articles and postings about the design of business object or entity classes. I currently have BusinessObjects and BusinessManagers (generated by CodeSmith); BusinessObjects have properties for table/column in the database; BusinessManagers have functions like GetAll, GetById, GetByOrderNumber.
My dilemma is that I want to add methods and logic to the BusinessObjects but fear that's wrong. From what I understand, this is a gray area. Most people say you don't want your classes to be "anemic". But it is also said that by adding logic to your BusinessObjects, it becomes more difficult to test -- which I don't understand why. Say I have an "Order" object (BusinessObjects.Object and BusinessManagers.OrderManager). After I process an order, I want to send an email. The three choices I see are -------------------------------------------------------------- 1. Order order = new Order(); ... order.SendEmail(); 2. OrderManager orderManager = new OrderManager(); Order order = new Order(); ... orderManager.SendEmail(order); 3. // some new class to hold business logic OrderLogic orderLogic = new OrderLogic(); Order order = new Order(); ... orderLogic.SendEmail(order); -------------------------------------------------------------- I want to do option #1. Similarly, if I want to save an object, I would prefer to say order.Save() instead of passing the order to some other class. This seems more object orientated to me. Passing a parameter to a function seems more like something I would do in C (i.e. a procedural language). Any opinions or suggestions would be greatly appreciated. Eric --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
