There are as many opinions as there are developers I guess, but without knowing much of your use cases I would...
<<But it is also said that by adding logic to your BusinessObjects, it becomes more difficult to test -- which I don't understand why.>> Me neither. Where have you heard this? <<After I process an order, I want to send an email>> To me, this probably include (at least) three objects. IOrder IProcessOrder ISendEmail [pseudo] (if you're not using an ioc container or similar) IProcessOrder p = new ProcessOrder(anOrder, new SendEmail()); p.LetsDoIt(); In real world scenarios however I would guess a lot of other services/components (and entities) would be involved. <<I want to do option #1 [snip: order.SendMail()]. 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. >> Some people agree with you. I definitely not, at least not if you're trying to be "object orientated". IMHO - it's not the responsibility of an Order to know how to get persisted nor to send an email. Finally, I would suggest you _not_ listening too much to replies like this or posts elsewhere. If you and your coworkers prefers and find it easier to work with a design like order.SendEmail() or order.Save(), it's probably the best choice for you - at least if the project is quite small. Good luck! /Roger -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Eric Sent: den 1 september 2009 19:54 To: nhusers Subject: [nhusers] Business Object (entity) Class Design 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 -~----------~----~----~----~------~----~------~--~---
