MBR IT/.NET 247 : Design on ASPFriends.com 'aspngarchitecture' list

Design

Messages

Related Types

This message was discovered on ASPFriends.com 'aspngarchitecture' list.

mail

About the dataset aproach vs oo aproach. After rewing the opinions here
and there, searching in msdn i found what i think, describes best this
situation. The "pet-shop" example, if you look at the panel discussion
in the pdc, the people that made dwamish, nile, fauvorites, etc..
discuss what they did and why. It very interesting to hear the story
about "pet-shop" it was encomended by microsoft to and indepedent
consulting firm with the purpose of showing java devolopers how to
migrate to .net (which is all that .net is about), so this consulting
firm decided that they wouldn't followa the classical OO aproach of java
and they favoured a small bussiness layer with logic in the store-
procedures. When they went to bench mark the app they suddenly found it
run 28 times faster than the java aproach and it used one third of the
code.
So why matter for OO, just because it fun to play with?. I think the
answer is simple "Look a your app domain!"
1) If your proyect is small. DataCentric aproach is simpler, faster and
smaller.
2) But is your proyect is big o last for a long time tha overhead of OO
pays back when you see that new bussiness changes can rapidly be solved
consuming your existing objects. Also bringing along what is the most
important aspect of OO (not inheritance, not poliformism, not
encapsulation) but self description. It's amazing to see that when new
programer are added to a proyect o they are replaced, the coded written
with OO aproach is so rapidly understood in conrast to Proecedural
aproach.
This even pays back when you are the only programmer and have to go back
to your old code, to fix it or change it. Object are more easy to
understand!!

Please respond back with your opinions.

Reply to this message...

Paul D. Murphy

So it seems that there is another debate about the middle tier on the =
architecture list. That doesn't surprise me; it's been about 6 months =
since the last one. I've always weighed in to this debate on the side of =
having 6 core modules in an application. The data layer, the engine, the =
collection, the class - ECC for the core object model and entity layer =
business logic - a fa=E7ade to wrap complex operations and utility =
classes or pipelines for operational stuff. I've found that I spend most =
of my time writing code in the DAL and ECC portions of the project. =
Fa=E7ade code is pretty simple to whip together once the lower layers =
are defined and debugged. Utility code is portable from project to =
project.

Originally I really liked the DataSet because it has some interesting =
features. It can be strongly typed with great ease in Visual Studio =
.NET. If you are using SQL server DB (I always do) you can construct =
visually a robust data tier to deal with persistence and creation in =
minutes with the Visual Tools. Those two points weigh in heavy for me; =
being able to construct a typed object model and a 100% working DAL in =
an afternoon means a lot to my income. It's great for disconnected data =
with the state tracking features. It has a solid object model for =
managing relationships. It has no way to deal with my business logic; =
which becomes a huge problem real fast. This really is a deficiency of =
the tool and not the DataSet or Microsoft's object model for dealing =
with data in .NET.=20

So I've always scratched the DataSet and used DataReaders to load up =
objects. The Microsoft Data Access Application Block helped =
significantly here, but there was still the issue of writing all the =
code for the middle tier infrastructure. It's time consuming and =
repetitive.=20

About two weeks ago I was wondering around internet reading articles =
about programming attributes and I stumbled across what appears to be =
the perfect solution to actually being able to use DataSets as the =
middle tier component. These guys wrote a group of attributes =
(http://www.newtelligence.com/news/AttributeBasedValidation.aspx) that =
simplifies validating data. Most of the 'class' code that I write is =
simple validation, managing 'change status', or transforming against an =
algorithm. The notion of separating out the generic work into an =
attribute is staggering. It's really a beautiful example of how to use =
Attributes. It's also a good model -- that works -- for dealing with =
transformations.

I've started a new project a couple of days ago and I'm taking this =
approach to the design of my application. It's really amazing how fast =
I'm getting work done. Almost 75% of the work is visual. The only code =
that I am having to write from scratch are the transformation =
attributes. So far I have been able to construct the complete Sql =
database visually (sans complex sprocs and triggers), construct the =
middle tier object model from the views and tables in the DB visually, =
construct the data adapters visually, and apply the business logic with =
attributes.

If you work in an environment where you do most of the coding or are a =
one man shop; take a look at using the Visual Tools this way and read up =
on these attributes. It makes work get done a lot faster.

Paul

-----Original Message-----
From: mail [mailto:Click here to reveal e-mail address]=20
Sent: Sunday, June 23, 2002 3:17 PM
To: aspngarchitecture
Subject: [aspngarchitecture] Design

About the dataset aproach vs oo aproach. After rewing the opinions here=20
and there, searching in msdn i found what i think, describes best this=20
situation. The "pet-shop" example, if you look at the panel discussion=20
in the pdc, the people that made dwamish, nile, fauvorites, etc..=20
discuss what they did and why. It very interesting to hear the story=20
about "pet-shop" it was encomended by microsoft to and indepedent=20
consulting firm with the purpose of showing java devolopers how to=20
migrate to .net (which is all that .net is about), so this consulting=20
firm decided that they wouldn't followa the classical OO aproach of java =

and they favoured a small bussiness layer with logic in the store-
procedures. When they went to bench mark the app they suddenly found it=20
run 28 times faster than the java aproach and it used one third of the=20
code.
So why matter for OO, just because it fun to play with?. I think the=20
answer is simple "Look a your app domain!"
1) If your proyect is small. DataCentric aproach is simpler, faster and=20
smaller.
2) But is your proyect is big o last for a long time tha overhead of OO=20
pays back when you see that new bussiness changes can rapidly be solved=20
consuming your existing objects. Also bringing along what is the most=20
important aspect of OO (not inheritance, not poliformism, not=20
encapsulation) but self description. It's amazing to see that when new=20
programer are added to a proyect o they are replaced, the coded written=20
with OO aproach is so rapidly understood in conrast to Proecedural=20
aproach.
This even pays back when you are the only programmer and have to go back =

to your old code, to fix it or change it. Object are more easy to=20
understand!!

Please respond back with your opinions.

| [aspngarchitecture] member Click here to reveal e-mail address =3D YOUR ID
| http://www.asplists.com/asplists/aspngarchitecture.asp =3D JOIN/QUIT
| http://www.asplists.com/search =3D SEARCH Archives

Reply to this message...

Ben Hyrman

From a supportability standpoint, I really hate to even think of triggers
(we've effectively outlawed them here). It is almost impossible to know what
kicks a trigger off or if it completes successfully. Triggers that kick off
triggers that you didn't even know about are even worse. From a purity
standpoint, I will put them on level with goto <linenumber> =)

My feelings on stored procedures are that they should be relegated to the
function of a data access point and that's it. That is, they should not be
performing any sort of validation or business logic at all. Business logic
through stored procs is fine until a database needs to be used by another
application or the business rules change. At that point, it gets expensive
fast.

It's cheapest to have a business user update business logic, followed by
maintenance programmers, followed by programmers, followed by DBAs (given
the going rates I've seen for each). To me, it makes sense to move
maintenance and longevity work as close to the end user as possible, where
practical.

While protecting the names of the guilty, let's say that my company bought a
large, expensive package a few years ago to perform core business functions.
This application put the majority of it's business logic in stored procs. Of
course, we elected to extend the package to get the functionality we
needed...and we extended it in the same manner as it was written, stored
procs. It will now cost half as much as we spent just to upgrade with the
main reason given is that all of the stored procs are so intermingled and
twisted that it will be a large effort for testing. So, if we spent $40mm on
inital work, it will take $20mm to upgrade.

From a more aestetic approach, I like to build my applications in a manner
where they do not rely on particular features of a database, or even a
database at all. This means that I do a fair amount of work, that I might be
better off not doing, in my app, such as ID generation and such. The flip
side is that I can use Access or SQL Server or MySQL with no problems at
all.

In this fashion, you start to see a lot of little service components pop up
that are reusable across domains. Object-Relational mapping objects can be
fast, reusable across domains, and an effective facade against databases.
Validation engines strike me as rather slow, but external to core business
objects, reusable, and updatable by business users.

So, in summary, I hate stored procs, although I think my response to them is
more reactionary than needed; I prefer the lego method of building
applications...after a few iterations, you have a great set of legos to
speed up development on the next application; and, after working as an
architect for a company that has added several new business units and gone
global in one year, objects that can be quickly extended to take on new
responsibilies are much better than anything hard-coded.

As a side note, wasn't the comparison against the Java pet shop on Oracle
App Server? afaik, Oracle isn't known for their speedy app servers.

[Original message clipped]

_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com

Reply to this message...

System.Data.DataSet

MBR BootFX
Best-of-breed application framework for .NET projects, developed by Matthew Baxter-Reynolds and MBR IT

	Copyright © Matthew Baxter-Reynolds 2001-2008. '.NET 247 Software Development Services' is a trading style of MBR IT Solutions Ltd.
	Contact Us - Terms of Use - Privacy Policy - www.dotnet247.com