Re: n-Tier development
- From: "Cor Ligthert [MVP]" <notmyfirstname@xxxxxxxxx>
- Date: Mon, 30 Jan 2006 16:45:23 +0100
CMM,
I see that you have well thought about it. However trying to get you out of
a loop you are in my idea in (or maybe I am in it and can you show me that).
What does it change when I communicate on whatever line to a middle Tier
DataServer or direct to the EndDataServer?
I wrote already that the needed information and sended updates stays for the
clients the same to whatever of those two and that goes over the same line
how small it is and what protocoll to detect if it is for the right client
is used.
You use your 1Gb line for probably the smallest amount of data and it is
even clean, so probably is no more than 2Mb used, assuming that you don't
use it for things as backup, replication etc.
In your picture
[Workstations] <dataset> Or whatever information transportcontainer
||||||||||||||||||||||
[App Server (DAL/Validation)]
| |
<retrieve/update statements>
| |
[Database Server]
Or tell me what I miss?
Cor
"CMM" <cmm@xxxxxxxxxx> schreef in bericht
news:ed%23kgCbJGHA.2828@xxxxxxxxxxxxxxxxxxxxxxx
>I know what you're saying... but I think you're missing my point...
>
> Talking about desktop WindowsForms apps here...
>
> You're off in your description of the "double-communication" (though I see
> what you mean). You have to think about how Ethernet works. In a 2-tiered
> app four updates sent to the database BROADCASTS eight (!) trips across
> YOUR ENTIRE LAN. This affects EVERY SINGLE user's workstation in your LAN.
> Isn't it better for you to just send *one* message and let DAL and DB talk
> to each other isolated and do their little 4-command conversation?
>
> You have to take a step back and think about this... The client
> workstation and the LAN-in-general are used for other things not just
> *your app.* There's web browsing going on, e-mailing being done, and Joe
> in the next cubicle downloading the VS2005 4 GB ISO file from
> msdn.microsoft.com. I'd rather a bunch of INSERT/UPDATE statements happen
> between the DAL Server and the DB Server (with the DAL on the same machine
> as the DB or through a dedicated switch- so the LAN at large is not
> affected).
>
> I think it is. In almost every single situation.
>
> [Workstation]
> |
> <dataset with changes>
> |
> [App Server (DAL/Validation)]
> | | | |
> <update statements>
> | | | |
> [Database Server]
>
>
> P.S. I don't advocate 3-tiered remoting between ASP.NET and the DB. In
> this case the Web Server and the DB Server should be hooked (and switched)
> together and communication between them is isolated and super-fast (if
> they're not on the same machine to begin with which a lot people do too!).
> The LAN caveats that I describe do not apply in this set-up as they're
> already Server-to-Server.
>
> "Cor Ligthert [MVP]" <notmyfirstname@xxxxxxxxx> wrote in message
> news:%23aPFMjaJGHA.424@xxxxxxxxxxxxxxxxxxxxxxx
>> CMM,
>>
>> Altough we completely agree about what you write about encapulation and
>> mixing this up with Tiers. Is in my opinion your calculation not correcte
>> and the way you tell that a real physical Tier needed as well not.
>>
>> To communicate with the middle tier on that seperate computer, you have
>> to communicate as well with that middle tier. However now it has to do it
>> twice, one time on your so called 1Gb line and the same as before on your
>> 100Mb line in your sample. The clientcomputer (which is not a terminal)
>> need the same amount of information and has the same amount of updates.
>>
>> Therefore there is only an extra piece of datacommunication introduced.
>> The transport of data on your 1Gb line.
>>
>> For me the multitier is right in the Terminal application situation (not
>> windowsclient emulating). In the windowsform situation I see no
>> advantages, while this Terminal situated 3 tier is already done by a
>> classic ASP or ASPNET application where the browser functions in a way as
>> a Terminal and the application as a middle tier.
>>
>> By the way probably before 1996 multi tier were more common because it is
>> a very good practise on a real Terminal based computer as Unix and other
>> Mainframes.
>>
>> Just my thought,
>>
>> Cor
>>
>>
>>
>>
>>
>> "CMM" <cmm@xxxxxxxxxx> schreef in bericht
>> news:ejF724ZJGHA.3492@xxxxxxxxxxxxxxxxxxxxxxx
>>> Don't listen to that other poster. I'll give you a really simple example
>>> on why programmers in the last five years have lost their minds.... and
>>> have forgotten all the lessons a lot of us learned in the 90's.
>>>
>>> What developers call "tiers" nowadays, I call simple "encapsulation"....
>>> NOT TIERS. Somewhere a mass hypnosis has taken root across the
>>> development world concerning this.
>>>
>>> Here's an example:
>>>
>>> 1) Supposse your DAL is on the client machine like the other user
>>> recommends (making it a 2-tiered App). You have a dataset where you've
>>> changed 10 rows. Calling Update on a DataAdapter with this dataset will
>>> result in your update stored proc (or update sql) being called 10 times!
>>> That's 10 network round trips.... across a busy 100-megabit network!
>>> 2) Even more likely you've changed one record in one table and 1 record
>>> in 3 other related child tables (Employe--EmployeAddresses--etc.).
>>> That's 4 round trips. Your app is now a VERY CHATTY application. A
>>> network's nightmare.
>>> 3) In a true N-Tier structure (a 3-tiered App where the DAL is an
>>> another machine) there's only ONE round trip with your DAL.
>>> 4) Now, your DAL and DB servers are connected via 1-gigabit(!)
>>> connection....(this is common)...and connected to each other via a
>>> dedicated switch (so their conversations don't swamp the network the way
>>> your old 2-tiered rinky dink app did).
>>> 5) ...Or even better are on the SAME server. The round trips don't
>>> matter AT ALL.
>>> 6) Now imagine that your client app needs to run on a simple VPN with an
>>> office overseas. Your old 2-tiered rinky dink app is TOTALLY UNUSABLE
>>> and not much better than your employees using an Access MDB on shared
>>> workgroup server a la Windows 3.1.
>>>
>>> Developers think that because they put their data access in a separate
>>> files that they're code warriors and doing something special. In fact,
>>> they're not doing much at all except achieving nice encapsulation
>>> (always a good practice!). They're creating simple 2-tiered apps that
>>> people were coding in 1996 and suffering later for it.
>>>
>>> P.S.
>>> ADO.NET 2.0 with SQL Server 2005 introduces "batch updating" which
>>> addresses some of these concerns. But there are HUGE caveats with batch
>>> updating that render it almost useless (like returning Id's from
>>> INSERTS, etc) and almost always require a "rescan" of the affected
>>> tables... rendering moot any performance gains gotten by using batch
>>> updating. Again, TRUE N-TIER development is the answer here.
>>>
>>> P.P.S.
>>> You use remoted objects quite easily.... (and building your own
>>> barebones remoting host is super-duper easy... but, if you need object
>>> pooling and stuff like that you'll need to run them in IIS or Windows
>>> Server Component Services).
>>>
>>> Dim o As IContactsService =
>>> Activator.GetObject(GetType(IContactsService), serverUri)
>>>
>>> where IContactsService is an Interface in a lightweight DLL that exists
>>> on the server and client. Optionally you can put the server components
>>> directly on the client.
>>>
>>> Check out these links
>>> -http://www.thinktecture.com/Resources/RemotingFAQ/default.html
>>> -http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/introremoting.asp
>>>
>>>
>>>
>>> "Steve Barnett" <noname@xxxxxxxxxxxx> wrote in message
>>> news:%23X12mQYJGHA.1388@xxxxxxxxxxxxxxxxxxxxxxx
>>>> Ok, I've never done n-Tier development and I'm getting confused...
>>>>
>>>> Assuming I have a business layer and a data access layer that may be
>>>> running on different machines, how does my business layer know where my
>>>> data access layer is running? What is it I have to do in the business
>>>> layer that "creates" the data access layer on the other server?
>>>>
>>>> Second, what do I pass between my business layer and my data access
>>>> layer? Should I be returning a dataset from the data access layer to
>>>> the business layer and letting the business layer convert it in to
>>>> business objects, or should my data access layer return business
>>>> objects?
>>>>
>>>> For example, assume my business layer deals with "Client" objects.
>>>> Should my business layer ask my data access layer to return it a
>>>> "client" object, leaving the data access layer to determine what that
>>>> involves, or does my business layer ask the data access layer for some
>>>> information from tables and then the business layer builds the client
>>>> object from the returned dataset(s). If so, who builds the SQL, which I
>>>> thought would be a DAL function.
>>>>
>>>> As you can probably tell, I could do with a simple (but practical)
>>>> tutorial on n-Tier development... anyone know of a good one as it
>>>> relates to DESKTOP based applications. Unfortunately, this app I'm
>>>> working on is not a web based app.
>>>>
>>>> Thanks
>>>> Steve
>>>>
>>>
>>>
>>
>>
>
>
.
- Follow-Ups:
- Re: n-Tier development
- From: CMM
- Re: n-Tier development
- From: CMM
- Re: n-Tier development
- References:
- n-Tier development
- From: Steve Barnett
- Re: n-Tier development
- From: CMM
- Re: n-Tier development
- From: Cor Ligthert [MVP]
- Re: n-Tier development
- From: CMM
- n-Tier development
- Prev by Date: Re: String Constructor (Char, Int32) not working?...
- Next by Date: Re: Asynchronously reading off a TcpSocket the best way
- Previous by thread: Re: n-Tier development
- Next by thread: Re: n-Tier development
- Index(es):
Relevant Pages
|
Loading
