Tight coupling...or, "the theme of the day?"

[James Hokes]

Hi, all.

Based on my experience with the .Net platform, and after reading numerous
tomes about it, I have come to the following conclusion (for right or
wrong):

The ADO.Net libraries seem designed primarily for extremely tight coupling
to the datasource. All of these adapters, datatables, relations,
strongly-typed datasets, etc. all focus on or rely indirectly on having
embedded sql in the project.

How does this tie in with the loosely-coupled architectures that I'm used to
building? How can I tie in complex stored procedures? Most of the n-tier
systems that I've been involved with have _NO_ embedded SQL in them - on
purpose; we rely heavily on stored procedures to put the logic on the server
and keep it out of the component code.

What am I missing here? I surely don't want to "drag" tables (the horror!)
onto my design surface. I don't want these apps to know anything _about_
tables, nor do I want umpteen types of database schema dependencies compiled
in. Also, I want ZERO logins on the RDBMS having direct table access. Next,
I see only very weak support for stored procedures in the majority of the
ADO.Net system. Most of it seems to be designed for the drag-and-drop
"developers", with little or no support for the hard-core, stored-procedure
based, abstracting-style of development. As far as I can tell, I can't even
get a strongly-typed dataset to represent the rows returned from a stored
procedure, unless I roll it by hand. Add in the lackluster support for NULL
data from the source and it doesn't look very appetizing at all.

Am I wrong here? I'd really like to know if I'm missing the boat on this.

Thanks,
James Hokes

 

[Sahil Malik [MVP]]

I both agree and disagree.

First I disagree about - the need to have embedded SQL.

What I agree about -

ADO.NET or ANY data access architecture means that - if you deviate too much
the database architecture, i.e. too many layers - then dude ur gonna have to
write those layers. But I don't see how any data access architecture lets
you get around that problem. If your business objects and "communication"
with the database is different from what the stored procs expect - because
maybe they have a lot of logic inside them, then you will have to work on
the translation.

BTW - it might be a wise idea to take away some of that logic out of sprocs
and into the business layer.

Again, I don't see why ADO.NET is a problem as far as stored procedures are
concerned. ADO.NET works just fine with stored procs.

BTW - the null thing you point out about - is thanks to .NET in general. I
agree, that's a royal pain.

- Sahil Malik [MVP]
http://codebetter.com/blogs/sahil.malik/