Re: Writing a DAL with TDD
- From: mgsram <mgsram@xxxxxxxxx>
- Date: Mon, 5 May 2008 09:39:44 -0700 (PDT)
On May 5, 12:32 am, "Cramer" <A...@xxxxx> wrote:
REsponses inline:
"Arne Vajhøj" wrote
Cramer wrote:
Just because it's theoretically possible doesn't mean that it's a good
idea (to design a relational database based almost exclusively on how it
will be used, which is what TDD would do).
It does not make sense to design a database after how it will not
be used.
Obviously a database should be designed after how it will be used.
No - not at all. To the contrary, a database should be designed to model
the "real-world" entities and attributes of the business. The
program/software, DAL and all, then needs to figure out how to interact with
that real-world representation of the business model in the database. The
scope, itself, of what gets included in the data model and subsequently
built in the database, is determined by how the application will be used -
or more accurately the role the application will play in the business.
You are therefore correct to say that it does not make sense to design a
database after how it will not be used. That makes no sense at all and it's
amazing that you would conclude that that is what I was saying after stating
in multiple places in this thread that a database should model the real
world of the business (or a subset thereof).
What I'm saying is "not a good idea" is to build a database based on how it
will be used *by the client software* including the DAL. It's in fact a bad
idea.
Absolutely. However when you set out with TDD, the objective is not to
satisfy the *client software*. It is to satisfy the user requirements.
DAL or no DAL, the user cares less. Don't get me wrong here. I m not
saying DAL is not required. All i want to say is you need to design
your Database as well ad DAL in the best possible manner that
completely satisfies user requirements - no less, no more.
Case in point: Say you need to provide a report that lists customers and
their phone numbers. TDD would have us build a single table, Customers, with
three columns: FirstName, LastName, and PhoneNumber. Then as requirements
evolve, we'd need to have two phone numbers. So you'd add a second phone
number to the Customers table. Your reports work, you go from "red to green"
in a matter of minutes, and in the TDD world all is well. But your data
model is suddenly violating 2nd Normal Form (if you don't know why that's a
problem, then you're in trouble... well, actually your employer is, but I
digress). Then you need a 3rd phone number and add 3rd column... you see how
this is going. Well, according to the TDD way of doing things (which, btw, I
really; like - just not for data modeling), we find that we need to refactor
("mercilessly, in fact). Now is when we start seeing why TDD is really; a
problemmatic way to go with designing a database. Because we didn't model
the real-world of the business up front, we're now breaking out our phone
numbers into a separate PhoneNumbers (or ContactNumbers) table. When we do
this, we break all of our queries that were based on one table being in
existance, and probably break all of the code that consumed the result set
of those queries. Yes, we *can* refactor this way, but it's probably the
most costly in terms of development time and effort. Now, contrast that TDD
approach to developing a data model with the approach that says we should
model the real world of the business. With that approach, we would meet with
subject matter experts early and have them identify the ways *they* need to
interact with their data, what data points are of significance to them
(within the mission of this particualar database). Before we write one line
of code or build one table or unit test, we know that we would need to track
multiple phone/contact numbers per customer - and therefore, starting on Day
One, we'd build separate Customers and ContactNumbers tables. No need to
refactor (which is TDD's calling card). From Day One, we have this database
normalized through at least 3rd Normal Form.
What you have narrated above is a possible situation that you could be
in when you have not understood the requirements clearly. It has
nothing to do with TDD. TDD does not prescribe following the above
steps, if you know from the beginning that you need to have 3 phone
numbers. The "Subject Matter Experts" (SME) should be your customers
and they should be able to tell you what they need. If the SME
initially required only one phone number, I see nothing wrong in
having a single phone number column and moving ahead; and yes, if they
come back later and ask me to adding more phone numbers, i would
refactor as necessary ( Note: if none of the 3 phone numbers are
optional, then there is nothing wrong in having 3 columns).
In short, yes, we *could* use TDD to design a datababase, but the
refactoring part is super expensive when we have to refactor database
structures... reason being is that when we break out tables (or combind
them) we break the queries that worked with the original table design. This
ripples directly to any stored procedures or application code that worked
with those queries.
Yes, the refactored changes does ripple into stored procedures,
application code etc. But then your tests should go RED and to get to
GREEN you will have to fix them. This way atleast you are saved from
introducing breaking changes in the software.
Moreover, can you gaurantee that once your DB has been designed, you
will never have to change the table structure ever ? I suppose not.
When you design an application for users and when users use the
system, they would certainly feedback and some of their feedback can
drive changes that may involve DB layer as well. How would you deal
with these changes, if you did not have any tests to cover?
The responses that stated that I could apply TDD to the DAL, and even use
TDD to design the relational database immediately lost all credibility.
I'm new to TDD, but not to data modeling and client/server business
application development. Anybody promoting the idea of applying TDD to
designing a database, IMHO, is dangerous to their employer. That's not
meant as an attack on anybody here personally. It's just a fact.
The only fact of that is that you have a very narrow definition
of TDD and seem incapable of understanding it when it is explained to you.
Just because I don't agree with something doesn't mean that I'm not
understanding what is being said.
If you believe that a DAL *should* be developed with TDD (and not simply
that it's theoretically possible), please provide some explanation (which
means more than making statements). You can say that pigs fly. But until you
provide some compelling logic, then very few people are going to agree with
you.
If it's so incredibly obvious - as you seem to think - then you should be
able to provide an example... just like I did above (with the Customers and
Contacts scenario). Come on - if it's so incredibly simple, then you should
be able to do this without any hesitation or problem. Just one simple
example of how it's good or better to develop a data model via TDD than it
would be to develop it according to the real-world business model.
I suggested doing a POC before. I m still open to it. Give me a
problem statement and lets change the requirements and see how it
fares. You have nothing to loose and perhaps there is something to
gain for all of us here.
BTW: I'm writing this not to defend anything - but simply to point out
how wrong you are about this.
Wise men listen more than they talk.
Agreed - and did you take a moment to consider what I was referring to when
I wrote that? Or were you just talking before you listened?
.
- References:
- Re: Writing a DAL with TDD
- From: Arne Vajhøj
- Re: Writing a DAL with TDD
- From: Cramer
- Re: Writing a DAL with TDD
- Prev by Date: Re: Decrypting a data protected by ProtectedData.Protect() on another PC.
- Next by Date: Re: does ShowDialog start new thread ?
- Previous by thread: Re: Writing a DAL with TDD
- Next by thread: Re: Writing a DAL with TDD
- Index(es):
Relevant Pages
|
