Programming practices

[JoeW]

I read a while back that "any object oriented programmer knows not to
store data in the user interface" what exactly does this mean and is
it the same as say querying a SQL database and have the results
returned to a text box or by using a while loop to simply write the
results to a web page as they are read from the datareader? I ask this
because I have quite a few web applications that use a lot of SQL
queries and while reading the values it simple does a Response.Write
with the html markup and values that were retrieved.For instance:

while (sRead.Read())
{
string _productName = sRead.GetValue(0).ToString();
string _productID = sRead.GetValue(1).ToString();
Response.Write("<a href='?id=" + _productID + "'>" + _productName +
"</a><br>");
}

Also is it necessary to use a DataSet in this situation or am I doing
it correctly?

Thanks!!

 

[Tom Leylan]

If you read that exactly it is a bit of "misquote" as it doesn't have
anything to do with OOP per se. The principles have been around a long time
(look up "MVC" model-view-controller) for more information.

The key idea is to separate "presentation" (the view) from the "data" (the
model). That wouldn't mean of course that a textbox won't have a value in
it but it does mean that shouldn't be where the data is kept. It's
transferred from the model to the textbox and from the textbox back to the
model. That way when other parts of the app (like the part that saves the
data) need to know the values they don't have to go find them as a text
properties of some textboxes on some form.

Tom

 

[Jon Davis]

It means that in an object-oriented system, the user interface should not
concern itself with SQL syntax.

IMO, you're doing it "correctly" (if it works, that is). It can just be bad
design. The good design / bad design principles are really only guidelines,
and these rules are made to be broken, but hopefully only in so much as you
simply don't have time to architect and implement a good design. Smaller
ASP.NET solutions may not need to bother with the "good design" philosophy
especially if, in the very long run, designing it and maintaining it ends up
taking more man hours than to just hack stuff together to make things work.
Not that you're hacking stuff together, I'm just comparing two extremes.

I admit I shudder at seeing database reads and writes and UI updates inside
the same methods, especially when raw HTML and raw SQL appear just lines
away from each other. That is not tier-isolated OOP. Tier-isolated OOP is,
simply, here's my SQL results, put it into a dataset. Here's my dataset, put
it into my strongly typed object array. Here's my strongly typed object
array, pass it down to my user interface bucket (a web form that requested
it). Here is my user interface bucket, pass it down to my user interface
controls. Here are my user interface controls, now output the data-bound
objects as HTML.

That's not as ugly as it sounds. It's just well organized. A form that
renders an ASP.NET repeater should call a method (i.e. a static method on a
business object) that retrieves a strongly typed List<T> or array of that
business object, based on certain criteria.When the method returns the
list/array, the form binds the list/array to the repeater, and moseys along
about the next task.

When working on a project that scales out in terms of complexity over time,
this is by far the better way of going about it than just querying SQL
Server for a dataset and writing out some raw HTML. Why? Because next week
your manager's gonna come to you and say, we got a new requirement for
something else that queries for the same data, but renders it different.
Now, are you going to copy / paste your SQL+HTML?? You'd have no choice,
really. But then he also tells you that your data results are wrong. So you
have to fix the SQL twice now. What you could have done instead was just
call on that same method to return a strongly typed list and databind it and
forget about it. You'd fix the SQL error once, in that method. Sure, your
repeater object will need some layout reconfiguration, but there you're not
looking at SQL. You're on a user interface object, dealing with user
interface issues.

Code isn't bade just because it's non-OOP... at least, not in the eye of the
beholder. It does indeed take experience and culture to get exposed to the
benefits and faults of OOP vs. non-OOP design. At my last job, I was writing
SQL executing in client-side VBScript / ADO Classic in a Windows application
for every other form rendered on the screen. Yes, this was 2006. My concerns
about how antiquated this was, and how much OOP could help us, were
completely ignored. I was so disgusted I bailed and found the best job I've
ever had working on ASP.NET-driven web solutions. There is not a day that
goes by that we don't chat a bit about better design methodologies in our
codebase. I'm heard, even if the others don't agree. I strive to clean up
ugly code with good object-oriented principles. I daily refacter code, both
my own and others' code, to make it more readable and more maintainable, for
everyone. It's part of what makes a pragmatic programmer.

Jon

 

[sloan]

Joe,

looping and using response.write is very "asp-ish". Don't do this anymore.

YOu can still use IDataReaders.

See
6/5/2006
Custom Objects and Tiered Development II // 2.0
http://sholliday.spaces.live.com/blog/

(or the may article for 1.1)


If you have multiple rows of data, then you can "bind" ( .DataSource = and
..DataBind() ) on objects like GridView, DataList and Repeater ..