Persist Data by Programming Against Interface
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
Optimizing Repository’s SubmitChanges Method
How do you abstract out your persistence code when using LINQ to SQL?
LINQ to SQL - mapping exception when using abstract base classes
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();