Making Entity Class Closed for Changes

Question

I have a database relationship as shown below. The domain objects are created based on LINQ to SQL ORM.

A payment comprises of Cash Payment and Gift Coupon Payments. Suppose the total amount of purchase is 550. It can be paid as following components

1 Gift Coupon Valued 300

1 Gift Coupon Valued 200

I Cash Currency Valued 50

I am inserting new payment records using the “InsertOnSubmit” function of ORM. The following code is working fine. However, if I the company is introducing a new payment component using credit card, I need to make changes to my “Payment” domain class. How do I make the payment class Open for Extension and Closed for Changes still using ORM?

Note: The Payment class has behaviors (E.g. GetTotalAmountCollected). I am trying to make the "Payment" class to satisfy OCP.

Note: There is a specific behavior for Coupon type. Is the Coupon issued date is less than 1/1/2000, it should not be used in calculation for Total Amount (i.e, CouponValue should be zero). Refer Refactoring code using Strategy Pattern also.

Note: I am using .Net 4.0

Reference:

1. Getting an error when using ObjectContext.AddObject with Entity Framework
2. Refactoring code using Strategy Pattern
3. Prefer composition over inheritance?
4. Code-first vs Model/Database-first
5. Strategy Pattern and Dependency Injection using Unity
6. C# Strategy Design Pattern by Delegate vs OOP
7. How to use the Strategy Pattern with C#?
8. Inheritance with EF Code First: Part 2 – Table per Type (TPT) http://weblogs.asp.net/manavi/archive/2010/12/28/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-2-table-per-type-tpt.aspx

C# Code:

public class PaymentAppService
{
    public RepositoryLayer.ILijosPaymentRepository Repository { get; set; }

    public void MakePayment()
    {
        DBML_Project.Payment paymentEntity = new DBML_Project.Payment();
        paymentEntity.PaymentID = 1;
        paymentEntity.PaymentType = "PurchaseP";

        DBML_Project.CashPayment cashObj = new DBML_Project.CashPayment();
        cashObj.CashPaymentID = 1;
        cashObj.CurrencyNumber = 123;
        cashObj.CurrencyValue = 100;

        DBML_Project.GiftCouponPayment giftCouponObj = new DBML_Project.GiftCouponPayment();
        giftCouponObj.GiftCouponPaymentID = 1;
        giftCouponObj.CouponValue = 200;
        giftCouponObj.CouponNumber = 124;

        paymentEntity.CashPayments = new System.Data.Linq.EntitySet<DBML_Project.CashPayment>();
        paymentEntity.CashPayments.Add(cashObj);

        paymentEntity.GiftCouponPayments = new System.Data.Linq.EntitySet<DBML_Project.GiftCouponPayment>();
        paymentEntity.GiftCouponPayments.Add(giftCouponObj);

        Repository.InsertEntity(paymentEntity);
        Repository.SubmitChanges();
    }
}

Repository:

public class LijosPaymentRepository : ILijosPaymentRepository
{
    public System.Data.Linq.DataContext MyDataContext { get; set; }

    public void InsertEntity(DBML_Project.Payment payment)
    {
        //Insert the entity
        MyDataContext.GetTable<DBML_Project.Payment>().InsertOnSubmit(payment);
    }

    public void SubmitChanges()
    {
        MyDataContext.SubmitChanges();
    }
}

Answer 1

For the problem that @Lijo tries to solve the abstract approach would be better

I think you can make a partial class on the CashPayment type that implements your own IPayment interface, which can be used through the whole application. This interface can then also be on CreditCardPayment:

Example:

public interface IPayment
{
     int Id { get; set; }
     int PaymentId { get; set; }
     //Other payment specific properties or methods
}

public partial class CashPayment : IPayment
{
    public int Id 
    {
       get { return CashPaymentId ; }
       set { CashPaymentId = value; }
    }

    //Other properties

}

public partial class CreditCardPayment : IPayment 
{
   //more code ...
}

Something on your EF context to get all payments

public partial class PaymentEntities //The name of your EF entities
{
   public IQueryable AllPayments
   {
      return this.CashPayment.Union(this.CreditCardPayment); //This is not good, but just an example. The abstract class approach would be better here.
   }

    public void InsertPayment(IPayment payment)
    {
         this.AddObject(payment.GetType().Name, payment);
    }
}

Answer 2

Maybe one alternative would be to take advantage of Inheritance, in the ORM as well. So that instead of having N collections, one for each type in the Payment Entity. You would have all of the subtypes in the same collection. And all those, added up would represent the entire Payment.

Maybe it would be easier to name things a bit differently. For example, let's consider the concept of a Purchase. Purchase should have a collection of Payments. And Payment could be an abstract class, from which Cash, Coupon, CreditCard, all inherit.

Having the model set up that way opens a great deal of possibilities regarding how you can solve certain problems. You can treat all payments the same and forget about distinct collections, plus have a great deal of control through polymorphism and double dispatch.

That way, if a new payment type arises, your model will remain the same, you will just have a new subtype.

Most ORMs nowadays support different persistence schemes for inheritance, that will help keep your data structure clean as well.

Answer 3

What is the added value of creating a new type for each type of payment ? I can see the distinction between a 'Payment by money', and a 'Payment done via a voucher'. I can agree to have two different types to make that distinction.

However, why make the distinction between a CashPayment, a CreditCardPayment, etc ... ? Do you have to store extra information depending on the type of payment ? Does the behaviour change ?

Why don't you just keep it simple, and add an extra property to the regular 'Payment' type, which acts as a discriminator and gives you the information how the payment was made (via creditcard, cash, .... ) ?

public class Payment {}

public class VoucherPayment : Payment {}

public class MoneyPayment : Payment
{
    public PaymentMode { get; set; }
}

public enum PaymentMode 
{
    Cash,
    CreditCard
}

Answer 4

You could define your model using table-per-hierarchy (http://msdn.microsoft.com/en-us/library/bb738443) which uses a discriminator (i.e., PaymentType in your case) column to specify the particular flavor of the payment you are making. Then you would be beholden to adding columns if new payment types required more data; however, EF is fairly flexible in terms of how you define entities and how those entities map to your data store. You probably could have a common set of columns like Number and Value and then go all sharepointy and add columns with generic names like StringValue1 to the database. You could then map those columns to better named properties in your conceptual model that would make more sense to your domain.

This basically flattens your database schema into a single table, but your model remains separate classes. You can subclass your Payment class for additional payment types without affecting either the data store or the Payment class; however, you would need to modify the model to add new payment types and map them to the appropriate columns.