I vote 5 for Sandeep Mewara and parmar_punit@yahoo.co.in. The reason for vote 5 for parmar is because of its simplicity and works correctly. My vote of 5 for Sandeep Mewara is because his concept works great too. Following are the explanations.
Dictionary is a simple and nice idea, but what if some users add
_sl.Add("@MyHeart", lovepulse);. If this should not happen then the caller should know the table structure prior
. What a tight coupling?
But a object model gives a
defined contract
. Somebody misunderstood object model as single object and downvoted Sandeep's answer. Let us have a look at how paramar's and Sandeep's answer together helps in this situation.
Objects have a novel concept
Encapsulation
Let us have an object model
public Interface IInsertableObject
{
public SortedList<string,object> getInsertData()
}
public class CommonObject:IInsertableObject
{
public string FirstName{get;set;}
public string LastName{get;set;}
public int Age{get;set;}
public virtual SortedList<string,object> getInsertData()
{
}
}
public class ExtendedObjectBasedOnTable:CommonObject
{
public DateTime birthDate{get;set;}
public SexEnum Sex{get;set;}
public overrides SortedList<string,object> getInsertData()
{
}
}
So your function will be like
public int Insert(IInsertableObject insertableObject)
{
SortedList<string,object> insertData=insertableObject.getInsertData();
}
insert(new CommonObject{ set the properties here.....})
insert(new ExtendedObjectBasedOnTable{ set the properties here.....})
So Sandeep's modal (Encapsulation and delegation) + Parmar's logic gives a better solution. The caller doesn't worry about persistance logic, but only need to know which object it can choose to match the parameters it is having. An another layer of factory goes here. But let us not make things further complex for OP.
Good luck