object vs transactional programming

  • Thread starter Thread starter ErwinB
  • Start date Start date
E

ErwinB

Hi all,
I have a question. Maybe it has been answered a zillion times, but I
don't seem to find the answer.
It's not so much a practical question, although it has practical
implications.

As we all know, C# is an OOP, i.e. we are supposed to treat entities
as objects (e.g. in the application I'm writing right now, there are
objects like "Site", "Customer", "WishList", etc). The data about
these entities are stored in a dabase.

With Windows Forms or ASP.NET controls, you can immediately bind to
the tables in the database. But doesn't good programming practice tell
us to use 3 layers : Presentation Layer (in which the object gets
displayed), Business Layer (in which business actions are performed on
or with the object), and Data Acess Layer (in which the object
interacts with its data source) ?

Using a control like DataGridView to bind immediately to a table seems
to skip these layers. Or should the DataGridView be considered as the
encapsulating object ?

I'm not trying to start up a theoretical debate here, I just want some
clear guidelines.

Thanks for your input

Erwin
 
I think you're discovering "RAPID" development vs "GOOD" development.

RAPID is just that....get something displaying/working as fast as you can.
With Asp.Net 2.0, MS put alot of RAPID stuff in.

Layered Development ( Pres / Biz / Data ) is not rapid (although for me,
when I do it, it seems just as fast or faster since I've been doing it so
long)......

RAPID != GOOD.

RAPID isn't always bad, if you're doing a demo or mock up, then sure.

But the cost of code is MAINTENANCE, not development costs. (Google
"software maintenance costs").

Thus for anything that is going to last or you need to maintain, then I
would avoid Rapid.

One issue with Rapid is that somehow, that "mock up" starts becoming the
base for the real project if its approved. I've seen this too much.
Treat a mock up like it is, throw away code.

...........

Mine is one opinion, there are others.
 
Sloan,
tnx for your RAPID answer (pun intented), I'm reassured now that I'm
following the right track.
Erwin
 
I use a 4 layer approach. Data Access Layer, Business Object Layer,
Presentation Service Layer, and Presentation Layer. So the DAL gets the data
from the database, The BOL holds the data. The PSL is used by the
Presentation Layer to coordinate real world operations on the BOL (like the
controller in the MVC pattern) and the presentation layer is the WinForms and
WebForms.
I bind my grids, and in winforms, the whole form normally to business objects.
 
Come to think of it, the last 4-5 years I did nothing else then
ASP.NET applications.
In Web applications, working with objects have little use : as soon as
the page gets rendered, the server forgets about it (and its objects).
That's why I used them rarely in the past.
(And I don't believe in putting huge chunks of data in Server
variables or cookies, that just clutters the roundtrips - you can as
easily retrieve the data from the database with every roundtrip. [with
AJAX things could be different, if Javascript was an OOP !])

A question for you, Ciaran : you say "BOL holds the data". Do your
objects holds the data in the dataset created and filled in the DAL,
or do you "map" the recordset to internal fields and properties ? Just
curious..

Erwin
 
i load business objects from either a datareader or datatable. I dont hold
the datatable past the DAL layer.
I have seen it done but I personally prefer to stick with proper objects. It
makes it easier when you want to create new ones and stuff.
 
Here are a few layered examples:
One of them is a tiered example. (WCF + Interfaces)
http://sholliday.spaces.live.com/feed.rss



WCF with Interface Development

Custom Objects and Tiered Development II // 2.0

Custom Objects/Collections and Tiered Development

There is a MS article located at the (bottom) URL I have above.

Find "bird's eye view" in my post, and then follow the MS trail to the
article.

I would bookmark that article and reread it about every 6 months.
 
I concurr with the "populate from datareaders".

My blog URL (above post) shows how to do this.
If you have Sql Server (or other rdbms) , you can use multiple resultsets
(with the IDataReader) to hit the db one time.
Check my sample(s) from the other post.




Ciaran O''Donnell said:
i load business objects from either a datareader or datatable. I dont hold
the datatable past the DAL layer.
I have seen it done but I personally prefer to stick with proper objects.
It
makes it easier when you want to create new ones and stuff.


--
Ciaran O''Donnell
http://wannabedeveloper.spaces.live.com


ErwinB said:
Come to think of it, the last 4-5 years I did nothing else then
ASP.NET applications.
In Web applications, working with objects have little use : as soon as
the page gets rendered, the server forgets about it (and its objects).
That's why I used them rarely in the past.
(And I don't believe in putting huge chunks of data in Server
variables or cookies, that just clutters the roundtrips - you can as
easily retrieve the data from the database with every roundtrip. [with
AJAX things could be different, if Javascript was an OOP !])

A question for you, Ciaran : you say "BOL holds the data". Do your
objects holds the data in the dataset created and filled in the DAL,
or do you "map" the recordset to internal fields and properties ? Just
curious..

Erwin
Click to expand...
Click to expand...
 
Great stuff, especially the MS article.
In all honesty, with my ASP.NET applications I am not all that far
from your point of view : my DAL also only delivers data, and nothing
else.
Thank you both for your input

Erwin
 
Back
Top