Re: n-Tier development

Also, to correct your diagram...

In a 3-tiered design....

[Workstation(s)] <dataset> Or whatever information transportcontainer
|||||||||||||||||||||| (LAN)
[App Server (DAL/Validation)] <retrieve/update statements>
|||||||||||||||||||||||||||||||||||||||||||||||| (NOT-LAN)
[Database Server]

Also, if the DAL was on the same machine as the workstations (2-tiered
design) the diagram changes to this:

[Workstation(s) /w DAL] <retrieve/update statements>
|||||||||||||||||||||||||||||||||||||||||||||||| (LAN)
[Database Server]

Communication with the DAL doesn't get diagramed because you're just passing
a simple reference to the Dataset to the DAL (there's no serialization or
marshalling involved). In fact when you see authors recommend calling
GetChanges() before passing data to the DAL.... this is ONLY for TRUE
n-tiered design... not when your DAL is on the client machine.


"Cor Ligthert [MVP]" <notmyfirstname@xxxxxxxxx> wrote in message
news:egVsXQbJGHA.916@xxxxxxxxxxxxxxxxxxxxxxx
> 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
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


.

Relevant Pages

  • Re: .Net development
    ... back to a central server when the user returns to the central location. ... I do not answer questions on behalf of my employer. ... > pharmacists will have to access a database server for data retreival. ... > And by the way, which way is better, a two tier architecture with a client ...
    (microsoft.public.dotnet.general)
  • Re: Date Format Conversion?
    ... >UDFs run on SQL Server. ... I do shit like that on a DATABASE SERVER not ... memory intensive udfs on client boxes so as not to degrade performance ...
    (microsoft.public.excel)
  • Database Server based on SQL database
    ... I want to build a socket based database server. ... How should the client ... And if the client can create the SQL strings that should work ok. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Newbie Client-Server select Query Question
    ... presumably the client tells the server to run a query for it. ... The client in this case just passes along the query it wants run, ... The server, however, is responsible for connecting to the DB, etc, but of course it is the database server that runs the actual query. ...
    (microsoft.public.dotnet.framework.adonet)
  • Re: ASP.NET: Fundementally Flawed Architecture
    ... So we've boilXwoad down your reasons for using ASP.NET to the availability of server-side XML processing? ... Because web server is far more simplified since it doesn't have to do the state or gui management. ... And that is reserving the middle tier for server side activities that really cannot be done in any other tier; because putting business logic in the middle tier is expensive from a performance perspective as it can become the performance bottle-neck in an architecture just like Db Servers run the risk of a bottle-neck. ... Over use of these tiers will result in unnecessary complexity and a degradation of performance as work is being done on the server when it could have been done on the client "at no cost". ...
    (borland.public.delphi.non-technical)
Loading