Re: Newbie object design questions

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

From: CDX (cdy_at_noSpamDiceNoSpamHome.Com)
Date: 01/28/05 

Date: Thu, 27 Jan 2005 21:57:16 -0500

Just to Chip in here :) on the topic of change. With my system change is
constant. It's not a matter of me not making the correct design in the
first place (not that that never happens), but rather the fact that the
system and business is always expanding to encompass new features. There
are new types of securities out there that traders want to trade, or we
now want to track the carry costs of each position. My system has been
designed to be flexible and change quickly to these demands, but it has
not (purposely) been designed to attempt to handle all possible
situations.

So it is essential that I can keep the business logic away from the
persistence and the UI. It just doesn't cut it having to deal with this
other logic when dealing with the "business object". That is why I'm
really taken back that we even need to have this discussion. I consider
this seperation to be very elementary to good object design and cannot
fathom why Microsoft would let something like this come to market. Let's
assume that they agree and come up with better frameworks for this. What
about all the code that's out there right now that worked around this
problem (or worse yet, ignored the separation). That sort of change is
going to be tough to swallow for a lot of systems.

Chip

Mike Ryan wrote:

> 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: How should I generate a primary key?
    ... Obviously the designer did not get all of the business rules from the ... Should the database ... A Work Order records the transaction of a truck service at a given ... This has got nothing to do with bad design, it is about the developer trying ...
    (comp.databases)
  • Re: Newbie object design questions
    ... generate typed datasets from stored procedures, ... When you come along to change things in the database, ... > database in the same way that the business thinks of them. ... > Mediating between these two points of view is what a business layer is ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Infinite Loops and Explicit Exits
    ... the whole payroll system would be dependent on proper database ... I design large systems the same way. ... Stored procedures ARE application code. ... any language, including Cobol. ...
    (comp.lang.cobol)
  • Re: DataSet is efficient in manipulating data?
    ... Our application design is a typical n-tiers design aplication ... where we have a ASP.NET UI, business logic layer, and a data access layer. ... The final system will have a web farm with about 10 machines, ... typically database update as use cases require ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: Writing a DAL with TDD
    ... idea (to design a relational database based almost exclusively on how it ... Obviously a database should be designed after how it will be used. ... that real-world representation of the business model in the database. ... However when you set out with TDD, ...
    (microsoft.public.dotnet.languages.csharp)