Why i should not add a "Save" Method to my Domain Entity? RRS feed

  • Question

  • Hi

    I always think about this question and at the end I can't find an answer based on design principles.

    "Why i should not add a "Save" Method to my Domain Entity?"

    Suppose I have a domain object named "Invoice" and it contains some related business rules, Why i should not couple “Invoice” class with an interface like "IInvoiceRepository" which dose CRUD for invoice  object and its family in the aggregate, then add a "Save" method in Invoice class and call that at appropriate time. Besides i can add a "Load" method to this class with an "Id" as a parameter for loading an invoice using that.

    Saturday, July 9, 2016 8:47 AM


  • Ok guys, I found out the answer. I reviewed the "Patterns of Enterprise Application Architecture book which has been written by “Martin Fowler” based on Chapter 10 “Data Source Architectural Patterns” my suggested approach is same as Active Record design pattern, Fowler has mentioned that in this pattern: “The data structure of the Active Record should exactly match that of the database: one field in the class for each column in the table. Type the fields the way the SQL interface gives you the data—don't do any conversion at this stage”; But in my approach there is no such constraint and it uses a Data Mapper Idea behind the sense.

    So for sum up I suppose it is ok to use such technique with pure ADO.Net codes when using a data mapper like EF is costly.

    Saturday, July 9, 2016 2:46 PM