Each client have different requirement.
Some clients may access property 2 & 3, Some clients may access property 4 & 5 and some other clients access all data member and so on.
I have created the simple test application, have a look on that.
The GetStudentInfo() method in service contract takes id and array of required properties from DataContract StudentInfo.
[ServiceContract]
public interface IStudentMgmtService
{
[OperationContract]
StudentInfo GetStudentInfo(string id,List
}
[DataContract]
public class StudentInfo
{
private string _StudentName;
private string _gender;
private string _Adderss;
private int _age;
private int _studentID;
[DataMember(EmitDefaultValue=false)]
public int ID
{
get {}
set {}
}
[DataMember(EmitDefaultValue = false)]
public string Name
{
get {}
set {}
}
[DataMember(EmitDefaultValue = false)]
public string Address
{
get {}
set{}
}
[DataMember(EmitDefaultValue = false)]
public string Gender
{
get { }
set {}
}
[DataMember(EmitDefaultValue = false)]
public int Age
{
get {}
set {}
}
}
The Service Implemention Code:
public class StudentMgmtService:IStudentMgmtService
{
public StudentInfo GetStudentInfo(string id, List
{
StudentInfo res = new StudentInfo();
if (value.Count != 0)
{
StudentInfo obj = new StudentInfo();
obj = BLL.BLL_DBLibrary.GetStudentInformation(int.Parse(id)); //Retrieves all the properties of StudentInfo class(i.e DataContract).
foreach (string item in value)
{
switch (item.ToLower()) // to get only Required properties of StudentInfo class.
{
case "id": res.ID = obj.ID;
break;
case "name": res.Name = obj.Name;
break;
case "address": res.Address = obj.Address;
break;
case "gender": res.Gender = obj.Gender;
break;
case "age": res.Age = obj.Age;
break;
default: break;
}
}
}
return res; // the result consist of only required properties of StudentInfo class.
}
}
Is this good approach?
Or
Is there any approach using Data Contract Surrogate class?
Andrew FensterPosted Mar 28, 2011, 1:01 PM
I would NOT do it this way for several reasons.
(1) You are sending each client a full StudentInfo object. Even though most of the properties have no values, you are informing the client of all your property names. You are telling the client information that you should not share.
(2) Requirements can change over time. New fields will be added. Old ones may be dropped or renamed. New clients will demand different data. Your system is not very flexible. You will force your clients to modify their code frequently. Even the clients whose requirements have not changed will be forced to make changes at times. They won't like that at all. They will be mad.
If your clients require such flexibility, I would drop the StudentInfo class and have your service sent each client an XML string.
Or you could return a class that provides ID and an array of key value pairs. In either case, we could add new data items (e.g., surname, birthday, email, etc.) without breaking any existing client.
There are multiple options here. The main thing is to return something that won't break when your clients want something different.