It depends on what you mean with "logic". Putting domain/business logic inside domain/business classes does not make it hard to test. It's usually a good thing, since it keeps behavior and data together, which is what object orientation is all about, and allows the domain logic to guard access to the data. However, making domain/business classes depend on infrastructure or technical details such as email and how to store themselves does make it harder to test, and to manage code quality in the long run.
Another alternative: IEmailService emailService = ...; order.SendEmail(emailService); Pass in a mock emailservice for testing. IEmailService would have something like SendEmail(string recipient, string messageBody). This pattern accepts that it may be reasonable to regard the logic for the contents of an order-email as part of the Order class, but still keeping the details of the email service out of it. On the other hand... why should an Order know anything about email at all? Totally different compared to for instance myOrder.AddOrderLine(product, quantity). Order.Save() seems quite weird to me... with NHibernate you would have ISession.Save(myorder), possibly by hiding the use of NHibernate behind the Repository design pattern. When not using NHibernate, I still would not want to insert database logic or file system handling or whatever inside the Order class. /Oskar 2009/9/1 Eric <[email protected]>: > > 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 -~----------~----~----~----~------~----~------~--~---
