OOP advice needed

[Mike]

I've got an ASP.NET web site that primarily uses the SqlDataSource for data
access tasks, and I am in the process of migrating it to use Business
Objects based on Imar Spaanjaars's articles here:
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416. This is my first
bash at OOP and I've hit a stumbling block.

I'm returning multiple records as a generic list in my DAL. I've got a
helper method which takes care of filling each "row" called FillDataRecord,
and a basic method that calls a proc to get the top 15 articles:

public static ArticleList GetList()
{
ArticleList tempList = null;
using (SqlConnection conn = new SqlConnection(Utils.GetConnString()))
{
SqlCommand cmd = new SqlCommand("GetArticleListForFrontPage");
cmd.CommandType = CommandType.StoredProcedure;
conn.Open();
using (SqlDataReader sdr = cmd.ExecuteReader())
{
if (sdr.HasRows)
{
tempList = new ArticleList();
while (sdr.Read())
{
tempList.Add(FillDataRecord(sdr));
}
}
}
sdr.Close();
}
conn.Close();
return tempList;
}

Now I need to return a list of articles by CategoryID:

public static ArticleList GetCategoryList(int categoryid)
{
ArticleList tempList = null;
using (SqlConnection conn = new SqlConnection(Utils.GetConnString()))
{
SqlCommand cmd = new SqlCommand("GetArticleListByCategory");
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.AddWithValue("@CategoryID", categoryid);
conn.Open();
using (SqlDataReader sdr = cmd.ExecuteReader())
{
if (sdr.HasRows)
{
tempList = new ArticleList();
while (sdr.Read())
{
tempList.Add(FillDataRecord(sdr));
}
}
}
sdr.Close();
}
conn.Close();
return tempList;
}

And again by ArticleTypeID:

public static ArticleList GetArticleTypeList(int articletypeid)
{
ArticleList tempList = null;
using (SqlConnection conn = new SqlConnection(Utils.GetConnString()))
{
SqlCommand cmd = new SqlCommand("GetArticleListByArticleType");
cmd.CommandType = CommandType.StoredProcedure;
cmd.Parameters.AddWithValue("@CategoryID", articletypeid);
conn.Open();
using (SqlDataReader sdr = cmd.ExecuteReader())
{
if (sdr.HasRows)
{
tempList = new ArticleList();
while (sdr.Read())
{
tempList.Add(FillDataRecord(sdr));
}
}
}
sdr.Close();
}
conn.Close();
return tempList;
}

The three methods are almost identical, and seem a good candidate for some
consolidation of code. However, I don't have a clue how I should go about
it. Any suggestions?

Thanks

Mike

 

[Peter Bradley]

Ysgrifennodd Mike:

I've got an ASP.NET web site that primarily uses the SqlDataSource for data
access tasks, and I am in the process of migrating it to use Business
Objects based on Imar Spaanjaars's articles here:
http://imar.spaanjaars.com/QuickDocId.aspx?quickdoc=416. This is my first
bash at OOP and I've hit a stumbling block.

I'm returning multiple records as a generic list in my DAL. I've got a
helper method which takes care of filling each "row" called FillDataRecord,
and a basic method that calls a proc to get the top 15 articles:

Is there any reason why you can't use DataSets (or Typed DataSets, which
are even better IMHO)? It's what they're for.

Re-usability and all that


Peter

 

[tomk148]

really isnt an OOP answer, but its not really appropriate here

Try writing a function that with this signature

private static ArticleList GetArticleList(string storedProcedureName,
List<SqlParameter> parameters)...

then wrap this function with each of the ones you have above.

 

[Mike]

Ysgrifennodd Mike:

Is there any reason why you can't use DataSets (or Typed DataSets, which
are even better IMHO)? It's what they're for.

Re-usability and all that

None at all, except that I haven't looked at that yet (Typed Datasets). I'm
trying to get my head around this approach first.

Mike

 

[Jon Skeet [C# MVP]]

The three methods are almost identical, and seem a good candidate for some
consolidation of code. However, I don't have a clue how I should go about
it. Any suggestions?

The only bit which changes is the SqlCommand, so create a method which
accepts a SqlCommand and does the rest.

(I don't think the code you've actually posted would compile, and the
code doesn't appear to associate the SqlCommand with the connection,
but in general you don't need to call Close on things if you've already
got them in a using statement.)

 

[Peter Bradley]

Ysgrifennodd Mike:

None at all, except that I haven't looked at that yet (Typed Datasets). I'm
trying to get my head around this approach first.

Mike

Hi Mike,

Been there. Done that. We originally went for returning simpler data
structures because we thought they'd be easier. We were wrong. It's a
couple of years ago, now, but I do recall that we put a stop to it after
our first project and settled for DataSets, where it's all done for you.

The only exception to this was a .NET 1.1 application that our managers
in their wisdom decided we didn't have time to do and outsourced to a
major contractor/consultancy. The code is the worst you've ever seen in
your life. It contains, for example, code to convert a DataRow in a
DataSet to an Array of Object (Ahem! It already *is* an array of
object!) We'd still be laughing if we didn't have to maintain it.

We now use Typed DataSets. If you want to know about Typed DataSets,
take a look at:

http://www.peredur.uklinux.net/TypedDataSets.pdf

(That version may be a bit out-of-date by now. If it is, I'll try to
remember to update it. But it should give you a start.)

HTH


Peter

 

[Mike]

The only bit which changes is the SqlCommand, so create a method which
accepts a SqlCommand and does the rest.

(I don't think the code you've actually posted would compile, and the
code doesn't appear to associate the SqlCommand with the connection,
but in general you don't need to call Close on things if you've already
got them in a using statement.)

It compiles ok, but you are right. It is incomplete and wouldn't run as-is
if I tried it.

Thanks for the suggestion and the tip about Close in a using statement.

Mike

 

[Jon Skeet [C# MVP]]

It compiles ok, but you are right. It is incomplete and wouldn't run as-is
if I tried it.

The code as you posted it would *not* compile - you're using both conn
and sdr outside the scope they're declared in. You should be getting
these errors (which I do when compiling a test program based on what
you posted):

Test.cs(23,13): error CS0103: The name 'sdr' does not exist in the
current context
Test.cs(25,9): error CS0103: The name 'conn' does not exist in the
current context

 

[PS]

None at all, except that I haven't looked at that yet (Typed Datasets).
I'm trying to get my head around this approach first.

Datasets and business objects are different approachs to modelling your
application. If you are using a domain model approach then use business
objects. If you are using a more table oriented approach typically found in
CRUD type applications then use datasets.

PS

 

[sloan]

see
http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!140.entry

 

[Mike]

The code as you posted it would *not* compile -

Absolutely right, John

It compiled ok because I *had* made those changes - after copying and
pasting into the post, but before sending the post. I forgot to update the
code in the post before clicking send....

 

[Mike]

Ysgrifennodd Mike:

Hi Mike,

Been there. Done that. We originally went for returning simpler data
structures because we thought they'd be easier. We were wrong. It's a
couple of years ago, now, but I do recall that we put a stop to it after
our first project and settled for DataSets, where it's all done for you.

The only exception to this was a .NET 1.1 application that our managers in
their wisdom decided we didn't have time to do and outsourced to a major
contractor/consultancy. The code is the worst you've ever seen in your
life. It contains, for example, code to convert a DataRow in a DataSet to
an Array of Object (Ahem! It already *is* an array of object!) We'd
still be laughing if we didn't have to maintain it.

We now use Typed DataSets. If you want to know about Typed DataSets, take
a look at:

http://www.peredur.uklinux.net/TypedDataSets.pdf

(That version may be a bit out-of-date by now. If it is, I'll try to
remember to update it. But it should give you a start.)

HTH

I will be trying the typed dataset approach next. I'm trying a number of
approaches so I can familiarise myself with what is involved in each one.
I come from a classic ASP background, so the ADO.NET code in the code-behind
approach is one I'm very comfortable with, and I don't have to worry about
others being able to maintain what I write (bit like your contactors LOL).
SqlDataSources seem brilliant to me for getting a simple app up and running
double quick, but sometimes still need ADO.NET code added, and I find the
mixture of ADO.NET and SqlDataSources "messy".

At the moment, I confess that I'm struggling to see the advantages of using
Business Objects...

Thanks

Mike

 

[Paul Shapiro]

I will be trying the typed dataset approach next. I'm trying a number of
approaches so I can familiarise myself with what is involved in each one.
I come from a classic ASP background, so the ADO.NET code in the
code-behind approach is one I'm very comfortable with, and I don't have to
worry about others being able to maintain what I write (bit like your
contactors LOL). SqlDataSources seem brilliant to me for getting a simple
app up and running double quick, but sometimes still need ADO.NET code
added, and I find the mixture of ADO.NET and SqlDataSources "messy".

At the moment, I confess that I'm struggling to see the advantages of
using Business Objects...

I think the biggest advantage of Business Objects is a place to add
additional logic beyond what's in the db. Functionality that "belongs" with
the object can be included with the object. I find it keeps the code cleaner
and easier to understand for future revisions.

 

[Mike]

Datasets and business objects are different approachs to modelling your
application. If you are using a domain model approach then use business
objects. If you are using a more table oriented approach typically found
in CRUD type applications then use datasets.

Your reply got me googling. Now I'm beginning to see the theory behind the
different approaches. Fascinating. Thank you very much for your
contribution.

Mike