n-Tier development

[Cor Ligthert [MVP]]

CMM,

I wrote about this,

Why? Well, because sometimes (often) they call for extra communication
with the DB and validating against data that the client machine does not
have and doesn't care about! For instance, "Did some *other* change in the
database invalidate this proposed update." This extra DB communication
(round trips!) should happen between the MiddleTier and the DB and not
through the LAN!

Don't you agree?

How can you solve this in the Middle Tier without interaction from the user.
The least you have to show is ("not accepted")

These errors are by the way called concurrency errors.
There is given information back by the DataBaseServer in the errorpart of
the datarow if this happens.

http://msdn2.microsoft.com/en-us/library/system.data.datarow.rowerror.aspx

What would your action be in the Physical Middle Tier without action from
the User?

Cor

 

[CMM]

How can you solve this in the Middle Tier without interaction from the
user.
The least you have to show is ("not accepted")

Same way you would solve (or not solve) it if the BL and DAL where on the
client machine. Only:

in the n-tier scenerio the process goes like this (look at the LAN steps):
1) There is ONE call to the MiddleTier (LAN).
2) Several calls between the MiddleTier and DB (NOT LAN).
3) "ERROR: reason(s)"
3) ONE call for the user to fix (LAN).
4) Several calls between the MiddleTier and DB (LAN).

in your 2-tiered app it goes like this

1) Several calls back and forth to the DB (LAN).<-- expensive
2) "ERROR: reason(s)"
3) Several calls for the user to fix back and forth to the DB (LAN).<--
expensive

Remember... in my example, in order to validate the database needs to be
queried for "subscriptions" because this data is NOT part of the original
dataset.

LAN= lots of stuff going on here (100mbit bandwidth shared by everybody...
e-mail, browsing, downloading, chatting, fileshare browsing)
NOT LAN= BL/DAL on same DB machine or via a high-speed switch.

These errors are by the way called concurrency errors.

No, not really... not in my example anyway. The error was triggered by a
table that has not changed... but rather contains data that that particular
app has no knowledge of at all and couldn't care less about. This is not
concurrency. This is a business rule.

There is given information back by the DataBaseServer in the errorpart of
the datarow if this happens.

http://msdn2.microsoft.com/en-us/library/system.data.datarow.rowerror.aspx

I love this feature of datasets. Not only can the middle tier set an error
on a dataset row but also on a specific column!.... I love it.

What would your action be in the Physical Middle Tier without action from
the User?

What would it be if the BL or DAL or whatever was on the client? Same thing
here.... though I don't think you're understanding what I'm saying.

 

[CMM]

Oops... Step 4 in my example should be
4) Several calls between the MiddleTier and DB (*NOT* LAN).

 

[Steve Barnett]

I very much appreciate this. I have been following the discussion, trying to
pick out as much as I can, but haven't passed comment as I felt there was
nothing I could contribute to the debate. Its been fascinating and I thank
you all very much for having it is such a civilised and constructive way.

Most useful.

My design actually called for the UI and BL to be on the same machine with
the DAL probably elsewhere, though I also need to cater for them being on
the same (laptop) PC.

Thanks
Steve