> --- Jeff Grigg wrote:
>> [ An aside on why the "business logic layer" (a non-XP
>> idea) is important: ]
--- Ron Jeffries <[EMAIL PROTECTED]> wrote:
> If I understand what you're saying -- and I think I do --
> we would want all access to the DB to go /through/ what
> you're calling the business logic layer.
Yes. Call it what you wish -- some kind of customizable logic that
the project team controls.
> Then we could, at least in principle, intercept the kinds of
> report definitions that Brad is telling us about, and adjust
> them so that they would still work. I think that would be
> difficult.
Ick! I agree. Intercepting, parsing, and rewriting arbitrary SQL
queries is a nasty problem.
"Database people" seem to say, "Don't worry about it; just create
views. Database views will solve all of your problems." Well, it
seems like a good idea, but I've never seen it work on real projects
in real life. ;->
Here's the alternative that I have in mind:
- We want to run the SNAFU report.
- Call "the application code," saying, "Please give me the data to
display on the SNAFU report. I'm providing the standard parameters
for this report -- that I want it for Customer #FOO-1234 for the
month of June 2004." (The customer number and date range could be
different for each run, but there are some set of parameters that are
always used to specify what data is needed for any given report.)
- The application code returns the data. With today's reporting
tools, returning the data in XML format is attractive.
When designing the SNAFU report, given the way that modern reporting
tools work, it would also be important to provide the following:
- "I'm about to set up the SNAFU report, 'painting' it, to be run
later. What parameters should I pass to 'the application logic' to
get the SNAFU report data? And what is the format of the data that
will be returned? (IE: Field names, sizes and types, and structural
relationships among elements.)"
- A good way to provide this information, to modern reporting tools,
is XML Schema.
> An objection to doing this, of course, is that if people
> "just access the database, they can do anything they need
> to do and don't have to pay programmers to do it." And
> that leads directly to the inability to change the schema.
> But it does have the appearance of lower cost, if not the
> reality. So we can understand why they'd do it.
Right: They want to avoid using the programmers. So they hire
another programmer, who works independently of the others. Now we
have inter-group coordination issues. Ouch! ;->
> I'm not sure that I'd characterize the business logic layer
> as being a non-XP idea. I take you to be saying that it is
> somehow counter to XP. I think it is consistent with XP,
> for two reasons:
>
> 1. We expect to always have the "right" design for what
> the system does, so that if it needs a BLL, we expect
> to have one.
>
> 2. Since we focus on business value first, an XP project
> is likely to /start/ with a rudimentary BLL, and
> there'd be little or no reason to move away from it.
Right. Unlike other development approaches or methodologies, XP
doesn't walk in the door saying, "We should have a three-tier
architecture; a recognized industry best practice." With XP, an N-
tiered organization and/or "business layer" would have to
be "justified" by customer story needs and refactoring to deal with
code smells.
But from what I've seen, Test Driven Development (TDD) projects
naturally separate the database layer, because it's hard to test
business logic that's all tangled up with a physical database. And
they tend to separate the top-level GUI, because it's hard to test
non-trivial business logic through a GUI. And I think they tend to
separate "business logic centric" code from "user interface centric"
code, as it's just puzzling and difficult to deal with both at once.
So I think that XP projects will typically end up with an N-tier
architecture with clean interfaces, due to the forces that act on the
project and the code.
> In any case, I fully agree that the business logic mediates
> all access to the database if we're to have the flexibility
> to change it.
And if there's one thing I can be sure about business users and
databases, it's that they're going to want more stuff added to it.
;->
To Post a message, send it to: [EMAIL PROTECTED]
To Unsubscribe, send a blank message to: [EMAIL PROTECTED]
ad-free courtesy of objectmentor.com
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/extremeprogramming/
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
