Kiran Ramaswamy
Kiran Ramaswamy

Reputation: 796

Instantiating list of an object

I'm sure this question has been answered before, but I'm honestly not sure how to find the answer, and my searching hasn't yielded any results; feel free to answer this question by closing the topic and pointing me to the correct question / answer.

Let's say I have a class representing a Member of my organization. The class has a constructor to instantiate the Member object, taking as a parameter the Member ID, and executing a database call to return the row representing the Member, along with whatever properties of the Member I'm interested in using.

What is the correct protocol for obtaining a list of members?

My database query is simple - I have a stored procedure which will return me the list of members that I'm interested in obtaining. But how do I represent that on the application level?

Right now, I have a constructor for the Member object that takes as an input a DataRow, and assigns all the relevant properties of the Member object. I'm then doing the following:

public static List<member> getList()
{
    DataTable dt = GetMemberList();
    List<member> memberList = new List<member>()
    foreach (DataRow dr in dt.Rows) memberList.Add(new member(dr));
    return memberList;
}

Upvotes: 1

Views: 633

Answers (3)

Rick james
Rick james

Reputation: 854

There is really nothing wrong with what you are doing currently.

        DataTable dt = GetMemberList();
        List<Member> memberList = new List<Member>();
        foreach (DataRow dr in dt.Rows)
        {
            memberList.Add(new Member(dr));
        }

Upvotes: 0

Travis J
Travis J

Reputation: 82287

GetMemberList is doing the work here, getList is merely an abstraction. What you are talking about though is a separation of concerns. Usually this is accomplished in a project with a database by separating out into layers, often referred to as an n-tier structure.

Pertaining to what you are asking about, this structure would contain a Data Access Layer (DAL) which handles the database interactions; a Service Layer which has the ability to manipulate the input and output of the DAL, and then return that data to a caller; and a Business Logic Layer, which would determine which service calls to make and how to compose the returned data.

How you implement that structure greatly depends on several factors:

  • size of your project (is this for a small business or for everyone)
  • size of your team (is it just you or are there many developers involved)
  • testing (is there any testing, and how large is its coverage)
  • timeline available (does it need to be done this week)
  • sensitivity of data (are you dealing with financial data)
  • personal preference (tabs or spaces or code cowboy)

Best practice would dictate different things depending on how those factors line up. If it is just you, then it is a lot more open to interpretation. If it is a team, then they probably already have guidelines for this type of thing.

I would suggest at the very least using a data access layer and a service layer.

Upvotes: 1

DanHarrigan
DanHarrigan

Reputation: 40

I'm not sure what your Member (I recommend using a capital M for your class) class looks like, but you can have your class constructor take the DataRow as a parameter and populate your properties like this: (I'm assuming property names and database column names here).

public class Member
{
    public Member(DataRow dataRow)
    {
        MemberID = Convert.ToInt32(dataRow["MemberID"]);
        MemberName = Convert.ToString(dataRow["MemberName"]);
    }

    public int MemberID { get; set; }
    public string MemberName { get; set; }
}

Not the best solution, but this should work with the code you have provided.

Upvotes: 0

Related Questions