Would love to hear comments on Class Architecture I became accustomed of
During my experience as a software developer I got used to a practice of creating Entity classes (or DTOs) and Manager classes. For example I'd create Customer with it's property getters and setters and then CustomerManager with all the methods related to Customer class (for example GetCustomer, GetOrders etc...). Don't know why, but it seemed appealing to me to have additional separation between properties and methods. But now I start to think if this approach is good or bad. I mean I'd rather have Customer.Get() than CustomerManager.GetCustomer(). I would like to hear your oppinions and suggestions ab开发者_运维百科out this. Are the differences purely aesthetic or is there anything to gain from either approach?
Thank you in advance, Community at Stackoverflow has always been very helpful. Keep up the good work!
I prefer CustomerManager.GetCustomer()
on the basis that:
- it's more self explainatory / self documenting
- Customer.Get() ... get what?
- seperation of concerns ... customers don't get themselves :)
To me a DTO is (or at least sounds the same as) a POCO; in both cases it's essentially a package of data, where as a full blown class (in the OO, DDD, BL sense) goes well beyond that.
Both a Customer
and a CustomerManager
class can have methods and properties that are suitable in the context of the business / application domain - but a DTO / POCO is not at that level.
精彩评论