By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,234 Members | 1,823 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 426,234 IT Pros & Developers. It's quick & easy.

To OOP, SQL DOM or DCOM?

P: n/a
pap
I would appreciate any thoughts on trying to take an OOP approach to
datacentric applications and the issues of performance and portability.

The diatribe is a bit long so...
See
http://www.papwalker.com/ref101/oopa.html

TIA
--

peter walker
Nov 12 '05 #1
Share this Question
Share on Google+
5 Replies


P: n/a
For one thing, much of the concept of a 3 tiered approach is not done simply
because we are trying to "scale" the application. A 3 tiered approach can
certainly help in the scalability since the business logic is running on the
server side, and NOT client side. Stuff like update code etc runs server
side, and thus does NOT cause network traffic.

However, the main thrust/reason for that 3 tiered approach is that we don't
want the business logic on the client side. Besides, a browser and some
little scripts is not the best IDE! In fact, writing code in ASP pages is
not that hot either.

However, why not use a 2 tiered approach? Why not simply put all the logic
into stored t-sql procedures?

The problem is that t-sql is a real lousily development platform to write a
payroll system. In fact, t-sql is not enough of knife for anything that has
a large degree of complexity. Don't get me wrong, but t-sql is fabulously
fine language for writing some sql update code. However, when you need to
write a complex payroll system, t-sql don't even come close.

Thus, to develop modern software ones needs a REALLY GOOD IDE AND DEBUGGER.
In other words, I need a fully powerful development platform with
subroutines, functions, objects, and all kinds of stuff that developers have
come to expect in any good development language. A good debugger, some
source code control is also needed for any large project. One needs the
whole nine yards for any serious software development.
Problem is, t-sql offers NONE of what we would call a rich development
environment. You can't un-leash a team of developers and say write a payroll
system in t-sql. It don't cut the mustard. You don't have objects in t-sql,
let alone simple things like collections etc.

So, developers quite quickly learned that the ONLY solution was to develop a
middle tier with the code. That middle tier is written using a good
development platform . As mentioned, the side benefit of this approach is
better scalability then a 2 tiered (thick client to sql server). With thick
client, the business logic is on the client side, and that causes additional
network traffic. There is also benefits to removing the business logic out
of the UI. So, the need here is a good IDE, and the code has to run server
side.

So, the whole com/dcom object idea in fact HAS caught on quite well. ASP.NET
and the new .net tools actually follow this 3 tiered model very well. Those
tools allow a incredible rich server side development platform. In fact, we
are even seeing some debates by some as to why even bother to use stored
t-sql procedures anymore! As long as the code is running server side, it is
not such a big deal anymore. It was not that we needed OO, or we needed a 3
tiered, but simply that developers were desperate to develop software with
good tools, and that software needed to run server side. To bad that in
place of t-sql we did not get vb-sql!

Regardless, all the basic use of things like reocrdsets etc can be used.
There is no need to "abstract out" the recordset code to something else.

Many now are actually suggesting that even more code be moved OUT of
sql-server into the middle tier. Also, moving the business logic to that
middle tier means LESS dependence on the front end and LESS on the server!

For best performance, stored procedures should still be used, but really,
most of the time if the code/data processing is running server side, then
all are quite happy.

All we really want is a nice rich development platform that allows rich
server side development. MS has given us that with the .net tools......

If you are developing small business applications, then I think a 2 tiered
approach with ms-access to sql-server is fine. The beloved ms-access is
still the best tool for most non web based business applications.

My thoughts on thin client vs .net:
http://www.attcanada.net/%7ekallal.m...tsand.net.html

My thoughts on when to use class objects in ms-access:
http://www.attcanada.net/%7ekallal.m.../WhyClass.html

--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
ka****@msn.com
http://www.attcanada.net/~kallal.msn

Nov 12 '05 #2

P: n/a
Albert D. Kallal wrote:

<snip>

So, the whole com/dcom object idea in fact HAS caught on quite well.
ASP.NET and the new .net tools actually follow this 3 tiered model
very well. Those tools allow a incredible rich server side
development platform. In fact, we are even seeing some debates by
some as to why even bother to use stored t-sql procedures anymore! As
long as the code is running server side, it is not such a big deal
anymore. It was not that we needed OO, or we needed a 3 tiered, but
simply that developers were desperate to develop software with good
tools, and that software needed to run server side. To bad that in
place of t-sql we did not get vb-sql!
Albert,

As you may know, apparently the next version of SQL Server is going to
include a significantly richer t-sql. I haven't been able to find a lot of
detail on what that means exactly, but for one thing it looks like we will
actually get VB.NET and C# integrated into the stored procedure development
environment. Again, details are sketchy (I've been doing research, but only
as I find extra time), but we may have vb-sql a ways down the road.

Regardless, all the basic use of things like reocrdsets etc can be
used. There is no need to "abstract out" the recordset code to
something else.

Many now are actually suggesting that even more code be moved OUT of
sql-server into the middle tier. Also, moving the business logic to
that middle tier means LESS dependence on the front end and LESS on
the server!

For best performance, stored procedures should still be used, but
really, most of the time if the code/data processing is running
server side, then all are quite happy.


One note: many recommend using stored procedures for secure data access as
well, with no permissions on tables and execute permissions on SPs only.

<more snip>

I always enjoy your thoughts on these issues.

--

Peter
Nov 12 '05 #3

P: n/a
"Peter" <pe******@nospam.net> wrote in message
news:bk************@ID-88800.news.uni-berlin.de...

Albert,

As you may know, apparently the next version of SQL Server is going to
include a significantly richer t-sql. I haven't been able to find a lot of
detail on what that means exactly, but for one thing it looks like we will
actually get VB.NET and C# integrated into the stored procedure development environment. Again, details are sketchy (I've been doing research, but only as I find extra time), but we may have vb-sql a ways down the road.


yes, I have herd this also!

And, as you can see, it makes a lot of sense! The folks at MS quite smart in
this regards!

I can't wait.

Gosh, right back to a rich programming environment just like we used to have
on the mini and mainframe computers! Yup...we have gone full circle!
--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
ka****@msn.com
http://www.attcanada.net/~kallal.msn
Nov 12 '05 #4

P: n/a
pap

"Albert D. Kallal" <ka****@msn.com> wrote in message
news:rt************************@news3.calgary.shaw .ca...
"Peter" <pe******@nospam.net> wrote in message
news:bk************@ID-88800.news.uni-berlin.de...

Albert,

As you may know, apparently the next version of SQL Server is going to
include a significantly richer t-sql. I haven't been able to find a lot of detail on what that means exactly, but for one thing it looks like we will actually get VB.NET and C# integrated into the stored procedure development
environment. Again, details are sketchy (I've been doing research, but

only
as I find extra time), but we may have vb-sql a ways down the road.


yes, I have herd this also!

And, as you can see, it makes a lot of sense! The folks at MS quite smart

in this regards!

I can't wait.

Gosh, right back to a rich programming environment just like we used to have on the mini and mainframe computers! Yup...we have gone full circle!
Indeed!
I have been muttering about the IT straightline roundabout for years.
The winterm thin client completes your concept by putting a 'dumb' terminal
back on the desk.
Still, software doesn't wearout. We have to keep milking the dollars out of
industry someway. If selling them bridges they bought years ago pays the
bills I am for it.
I have become mercenary (realistic) lately.

peter walker


--
Albert D. Kallal (MVP)
Edmonton, Alberta Canada
ka****@msn.com
http://www.attcanada.net/~kallal.msn

Nov 12 '05 #5

P: n/a
pa*******@ozemail.com.au.nospam (pap) wrote in
<k2*********************@news-server.bigpond.net.au>:
I have been muttering about the IT straightline roundabout for
years. The winterm thin client completes your concept by putting a
'dumb' terminal back on the desk.
Still, software doesn't wearout. We have to keep milking the
dollars out of industry someway. If selling them bridges they
bought years ago pays the bills I am for it.
I have become mercenary (realistic) lately.


To be fair, we are getting something in terms of richness of user
experience and enhanced functionality and reduced development time
for the costs. It's not a shell game where we're spending money and
getting absolutely nothing for it.

The main question is: is the benefit of the new enough to justify
the cost differential over the old? When the answer is NO, you
stick with the old.

That's why many of us are still doing A97 applications, because the
answer for the customers in question was a resounding NO.

But it's not always that way.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 12 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.