Persist Data by Programming Against Interface

Question

I have a IBankAccount interface that I will be passing to the ApplicationService. The changes made on the account objects (in the ApplicationService project) need to be persisted in the database. The repository receives the changes using IBankAccount interface. How can I persist this data into database? This is implemented using LINQ to SQL.

Note: Following is a comment from Scott in http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx "Add the interfaces to your LINQ to SQL data model classes. The LINQ to SQL classes are partial classes - which means you could add the interface directly to them."

public class LijosSimpleBankRepository : ILijosBankRepository
{
    public System.Data.Linq.DataContext Context
    {
        get;
        set;
    }

    public virtual void UpdateAccount(DomainInterfaces.IBankAccount iBankAcc)
    {
        DBML_Project.BankAccount  bankAccount;
    }

}



namespace DomainInterfaces
{
public interface IBankAccount
{
    int BankAccountID { get; set; }
    string AccountType { get; set; }
    System.Nullable<System.DateTime> OpenedDate { get; set; }
    string Status { get; set; }
    System.Nullable<int> AccountOwnerID { get; set; }
}

}

namespace DBML_Project
{
public class FixedBankAccount : BankAccount
{
    //Note: BankAccount already implemnts IBankAccount
}

public class SavingsBankAccount : BankAccount
{
    //Note: BankAccount already implemnts IBankAccount
}  

//The auto generated calss is made as abstract
[global::System.Data.Linq.Mapping.TableAttribute(Name="dbo.BankAccount")]
[InheritanceMapping(Code = "Fixed", Type = typeof(FixedBankAccount), IsDefault = true)]
[InheritanceMapping(Code = "Savings", Type = typeof(SavingsBankAccount))]
public abstract partial class BankAccount : INotifyPropertyChanging, INotifyPropertyChanged, DomainInterfaces.IBankAccount
{
      ..
    }
}

READING

@Boomer I am receiving only an interface in the repository method. Your suggestion won't work — LCJ, Jul 02 '12 at 10:07
If you know that your IBankAccount parameter will definitely be of type BankAccount, you could just cast the object...? — Shaul Behr, Jul 02 '12 at 11:39
@Shaul. But that doesn't offer the required help.. The parameter should be of type BankAccount. That means the client must know about BankAccount (to pass the parameter to the function) - not only the interface. — LCJ, Jul 02 '12 at 12:05

Ladislav Mrnka · Answer 1 · 2012-07-02T10:07:37.910

3

Your repository should accept BankAccount - not IBankAccount because Linq-to-sql doesn't know what is IBankAccount and compiler doesn't allow you to store it without casting it first to BankAccount (that can obviously fail at runtime if IBankAccount instance is not a BankAccount).

Once you have BankAccount you simply call:

Context.BankAccounts.Add(account);
Context.SubmitChanges();

edited Jul 02 '12 at 10:07

answered Jul 02 '12 at 09:55

Ladislav Mrnka

360,892
59
660
670

Thanks. However that will not be "programming to an interface", isn't it? Following is a comment from Scott in http://weblogs.asp.net/scottgu/archive/2007/06/29/linq-to-sql-part-3-querying-our-database.aspx - "Add the interfaces to your LINQ to SQL data model classes. The LINQ to SQL classes are partial classes - which means you could add the interface directly to them." This suggestion does not work in our scenario. Is there a way to make it work? – LCJ Jul 02 '12 at 11:28

score 0 · Answer 2 · answered Jul 02 '12 at 18:27

As far as I understand you need to model a banking system. This mean dealing with bank accounts. This is tough business that is no "Hello World!"-type information technology.

Basically with bank accounts you need to :

Read details (such as account name, value, etc
Debit account
Credit account
Terminate account
Create a new account
... and other operations

The debit and credit operations are the most "transactional" operations of them all since these mean that you'll be editing two accounts at a time and you want to succeed both editings or fail both at once.

This, again, is a risky business since it involves checking a lot of business rules beginning with having enough money on the account (that is not that simple since having an overdraft account means you can go below zero) all the way to ensuring there is a durable transaction that substracts money from one account and adds money to another one.

Also you must check that a person does not try to transfer negative amounts of money because that will be literally stealing money from other accounts. And the list does not stop here. Scott Hanselman worked in a bank for some time and he might be of some help regarding what needs to be checked.

All in all, my response seems to be a "not worthy" one and you might just as well downvote me but, again, the subject is too deep to be covered in a stackoverflow response.

Sorry.

Persist Data by Programming Against Interface

2 Answers2

Linked