Re: Newbie object design questions

From: Mike Ryan (CANSPAMmryan5_at_gmail.com)
Date: 01/27/05 

Date: Wed, 26 Jan 2005 23:17:15 -0500

Bruce,

All great points, IMO, and I agree.

I think the use of stored procedures as (yet another) layer of
abstraction can help with some of the issues you've mentioned. You can
generate typed datasets from stored procedures, thus avoiding the
one-to-one table mapping. Of course the usual drawback there is having
another separate collection of logic to maintain and it isn't the "big"
solution to these problems. SOA is. ;)

- Mike

Bruce Wood wrote:
> One of the problems I've battled over the years is the tendency of
> applications, which multiply like rabbits, to know too much about how
> the data is structured, essentially casting your database schema in
> stone. When you come along to change things in the database, kaboom! a
> bunch of (usually business-critical) applications blow up because they
> assumed such-and-so about the data.
>
> Another problem is that things aren't necessarily stored in the
> database in the same way that the business thinks of them. This can be
> by accident (original programmers didn't understand the business well
> enough) or by design (you can make more effective use of the database
> by folding two business entities into one table, or having multiple
> tables storing information about one business entity).
>
> I agree that modern databases have come a long way in solving the first
> problem. Changing the length of a field no longer trickles out to the
> application and blows it up (particularly in .NET where you have
> dynamically sized strings). You can add columns to a table without
> affecting applications that don't care about those columns. To that
> extent, it's a fair question to ask how much more engineering against
> change is cost-effective.
>
> However, as an example, what happens if I normalize a database table
> into two tables (a lookup and what's left of the original table)? Oh, I
> know: we're all supposed to design database schemas with everything
> normalized from the outset... and we all do, right? :*) You have to
> have some way of allowing old applications to see the data as if it
> were still denormalized, or you have a lot of rewriting to do just for
> an internal reorg of your data. Ugly. Or, even more ugly, you don't
> normalize the data because it would cause too much code churn, so you
> just live with it the way it is and it gets worse and worse....
>
> The second problem is more difficult, I think: for business reasons,
> technical reasons, or poor design, your database tables don't map
> one-to-one onto business objects. Now what? For example, where I work,
> a lift, or pallet is a stock item, but from the business's point of
> view it's a special stock item with special rules and operations
> associated with it. In object terms that sounds like a subclass to me,
> but in the database it's just another row in the inventory master.
> Mediating between these two points of view is what a business layer is
> supposed to do, but I'm having trouble imagining how you do that if
> your business entities are auto-generated from database tables.
>
> As I said, my impression is that Microsoft is looking to Web Services
> to save the day here: the business layer lives on the server side, and
> delivers data to the client organized in business terms, no matter how
> it happens to be stored in the database. The client can then accept the
> data as an ADO.NET dataset, secure in the knowledge that the schema of
> the dataset depends upon the wsdl (the Web Service contract), not the
> organization of the raw data. Of course, the contract can always
> change, but that's a business-level, logical change, not a data
> reorganization.
>

Relevant Pages

  • Re: Application logic and Business logic
    ... you need to handle PCs, windowing interfaces, new ATM networks, POS networks, ... Would you rather your business logic be wrapped-up inside the dumb-terminal ... business layer to have hardwired itself to a specific table layout is nearly ... Better to treat the database as a huge object that hides its data (table, ...
    (comp.object)
  • Re: "Business Objects" and the DAL
    ... layer talks to the layer next to it. ... business entity returned that up to the UI for binding to a grid. ... If a database table column names ... Each could be considered a "pattern", ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Returning typed DataRow from WebMethod
    ... So I've created a typed dataset from my database (a table called ... business layer doing all the business logic, ... these objects from my business tier to my presentation tier. ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: Newbie object design questions
    ... It's not a matter of me not making the correct design in the ... So it is essential that I can keep the business logic away from the ... > generate typed datasets from stored procedures, ... When you come along to change things in the database, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Multilayer applications
    ... > you from being able to make the direct database calls from your GUI. ... I supposed that GUI and the busuness logic layer are different instances. ... I use Sql Queries from my business ... Do you always use the Stored Procedures and never an implemented SQL code? ...
    (microsoft.public.dotnet.languages.csharp)
Quantcast