“Do not use Abstract Base class in Design; but in Modeling/Analysis”

后端 未结 2 1867
无人共我
无人共我 2020-11-29 10:37

I am newbie to SOA though I have some experience in OOAD.

One of the guidelines for SOA design is “Use Abstract Classes for Modeling only. Omit them from Design”. Th

2条回答
  •  一向
    一向 (楼主)
    2020-11-29 11:00

    I would go pretty much with what others have said here, but probably needs to add these:

    • Most SOA systems use Web Services for communication. Web Services expose their interface via WSDL. WSDL does not have any understanding of inheritance.
    • All behaviour in your DTOs will be lost when they cross the wire
    • All private/protected fields will be lost when they cross the wire

    Imagine this scenario (case is silly but illustrative):

    public abstract class BankAccount
    {
        private DateTime _creationDate = DateTime.Now;
    
        public DateTime CreationDate
        {
            get { return _creationDate; }
            set { _creationDate = value; }
        }
    
        public virtual string CreationDateUniversal
        {
            get { return _creationDate.ToUniversalTime().ToString(); }
        }
    }
    
    public class SavingAccount : BankAccount
    {
        public override string CreationDateUniversal
        {
            get
            {
                return base.CreationDateUniversal + " UTC";
            }
        }
    }
    

    And now you have used "Add Service Reference" or "Add Web Reference" on your client (and not re-use of the assemblies) to access the the saving account.

    SavingAccount account = serviceProxy.GetSavingAccountById(id);
    account.CreationDate = DateTime.Now;
    var creationDateUniversal = account.CreationDateUniversal; // out of sync!!
    

    What is going to happen is the changes to the CreationDate will not be reciprocated to the CreationDateUniversal since there is no implementation crossed the wire, only the value of CreationDateUniversal at the time of serialization at the server.

提交回复
热议问题