Question

In sql server, I have Students and Departments tables. I want to get Student records from Student table; with their Department data from Departments table(so i joined them) and show them in an asp.net page.

In asp.net I created a Student class type to use in list in asp.net codebehind. The list, takes Student class type data like this:

List<Student> lst = new List<Student>();

But I need to get Students with their Department datas. So I created a custom class in asp.net side called StudentsAndDepartments.

Now the list takes this class:

List<StudentsAndDepartments> lst = new List<StudentsAndDepartments>();

My question; do I have to create, for every query I make, an another new custom class? If I create a custom class for every query I use, there are being too many classes inside the solution. I think I'm doing wrong.. What should I do? Thanks for helping..

Was it helpful?

Solution

You do not create a "StudentsAndDepartments" class.

What you are doing here is trying to "flatten out" the domain model, and use one class to represent something that is better defined as a relationship.

You create your domain model. And relate them.

public class Student
{
public string LastName
/* the above is an example 'scalar' property on the Student.  you'll have others like FirstName, StudentIdenficationNumber, etc, etc. */
/* below is the 'relationshiop' property, use one of the two below but not both */
public ICollection<Department> Departments;
/* or */
public Department ParentDepartment;
}


public class Department
{
public string DepartmentName
public ICollection<Student> Students;

}

Then you "hydrate" the domain model.

Now this is where things can really vary.

Entity Framework with POCO can do this.

ADO.NET can do this. You write "Serializers" which convert IDataReaders into your object model. This is manual-mapping. With ADO.NET, you may write different stored procedures...

dbo.uspStudentsGetAllWithParentDepartments
dbo.uspDepartmentsGetAllSimple
dbo.uspDepartmentsGetAllWithChildrenStudents

something like that.

Now, where I digress from others usually.

I do NOT write JOIN SQL statements. I write 2 separate SQL statements (in ONE stored procedures) to get my data.

dbo.uspStudentsGetAllWithParentDepartments

would like like this

Select st.EmpKey, st.LastName, st.FirstName from dbo.Student st


Select dept.DepartmentKey, dept.DepartmentName from dbo.Department dept where exists (Select null from dbo.Student innerStud where innerStud.ParentDepartmentKey = dept.DepartmentKey )

Now, Entity Framework can do this sql-writing for you, but it is a start-up cost if you've never seen it before.

What my Microsoft-only friends won't mention is that EF does not support the .Merge() function like NHibernate does (another ORM tool). Which is a deal breaker to me. But that's a deeper discussion.

Define your domain-objects, their relationships, and then ask questions about "what's the best way to hydrate my domain-model based on my current skill-sets" (or without the skillset part if you're open to new ways)

Here is a link to another answer I posted...which is the serializer code for the ado.net way of hydrating your objects.

Why is DataTable faster than DataReader

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top