[ dusty @ 29.01.2004. 07:56 ] @
Pozdrav.

Imam jedno teoretsko pitanje. Recimo da pravim jednu klijent aplikaciju u C# koja ce da se kaci na neki SQL server preko ADO.Net-a. Baza ce eventualno postati dosta velika, a klijenti su osrednje mashine. Da li bih ja trebao da isprogramiram optimizaciju pristupa (npr. da ucitavam samo odredjen broj zapisa) kako se klijenti ne bi zagusili, ili to .net framework preuzima na sebe ?
[ Željko @ 29.01.2004. 08:24 ] @
Mislim da se tvoje pitanje ne odnosi na ADO.Net tj. .net framework, nego pre na sam dizajn tvoje aplikacije. Jer ako ti pokusas da iz baze povuces 10000000 rekorda nikakva optimizacija ti nece pomoci. Znaci prvo treba da napravis dobar dizajn tvoje aplikacije, da se odlucis za nacin realizacije (da li ce biti obicna klijent-server aplikacija ili nesto slozenija n-tier aplikacija). Ako se odlucis za n-tier, kako ce slojevi medjusobno komunicirati (da li ce biti u okviru jednog app domena, ili u razlicitim app domenima pa ces koristiti remoting)...
Takodje obrati paznju da .net aplikacije ipak rade sporije, a ti rece da su ti klijenti "osrednje masine".

pozdrav Željko
[ Toni_Spajic @ 31.01.2004. 12:37 ] @
Pozdrav,
Mene takođe jako muči ta sporost .net-a. Mislim da sam negdje pročitao da će Yukon omogućiti asinhroni pristup punjenju Data Set-a (ili neke druge klase)
i da će Yukon znati raditi Paging, što bi trebalo , ja se nadam da poveća performanse..
Inače, dok sam radio aplikaciju, jako sam pazio da se niti u jednom trenutku
korisniku po defaultu ne daju svi slogovi , nego samo Top 20, a kad mu
zatreba neki skup, on to filtrira. Mislim da je ovo dobar pristup, jer
u slučaju kada korisnik treba ispis svih slogova (to nije svakodnevno), on je spreman da to i sačeka, dok u svakodnevnom radu, njegov zahvat nikad nije tako velik nego tek 10-tak 20 - slogova.

Međutim, rad s bazom nije tako spor, koliko učitavanje formi , kontrola itd.
(da budem iskren, nemam pojma što jede memoriju kod .net-a)

Da li smo svi mi fulali alat kad smo izabrali .Net za osrednje mašine?
Ili da krenemo razmišljati o 3 tier aplikacijama
( da li će to pomoći da se ubrza GUI) ?

ili da čekamo da dođe naših 5 minuta (kad će više!!!)?!

ili da čekamo kombinaciju Yukon - Whidbey?

(btw- kako bi se zvao pristup gdje se na recimo 3 mašine vrte server aplikacije
koje ravnopravno djele sve resurse (kad se isključi npr. mašina 2, performanse aplikacije opadnu - n-tier?))
?

[ Toni_Spajic @ 31.01.2004. 12:42 ] @
Željko,
Kao što se vidi iz mog zadnjeg posta, nisam radio n-tier.
Malo sam isprobao ovaj remoting, i to mi je jasno,
ali ovaj drugi pristup koji navodiš
okviru jednog app domena koji ne koristi remoting,
aplikacija se vrti na serveru je li?
Kako ide ta fora i koje su joj mane a koji nedostatci u odnosu na remoting?
[ dusty @ 02.02.2004. 07:17 ] @
Citat:
Željko:
Mislim da se tvoje pitanje ne odnosi na ADO.Net tj. .net framework, nego pre na sam dizajn tvoje aplikacije. Jer ako ti pokusas da iz baze povuces 10000000 rekorda nikakva optimizacija ti nece pomoci.


Tja, na to sam i mislio. Znači ipak je trebam da pazim koliko će se zapisa učitavati, tj. da optimizujem čitanje iz moje aplikacije.

Citat:

realizacije (da li ce biti obicna klijent-server aplikacija ili nesto slozenija n-tier aplikacija). Ako se odlucis za n-tier, kako ce slojevi medjusobno komunicirati (da li


Za sada sam zamislio da bude klijent-server, pošto još nisam radio sa n-tier. A ne znam šta bih dobio ako bih napravio n-tier aplikaciju, pošto aplikacija neće da se menja kada bude napravljena, a neće ni biti potrebe da se pristupa sem iz lokalne mreže.

Citat:

Takodje obrati paznju da .net aplikacije ipak rade sporije, a ti rece da su ti klijenti "osrednje masine".


Pa, mašine su bedne sa pentium I procesorima. Nebitno mi je koliko će trebati da se aplikacija učita, bitno mi je da pristup dovoljno brzo radi, ali mašine su sa 32-64MB :(

Hvala na savetu, dusty.
[ Željko @ 02.02.2004. 14:54 ] @

Citat:
U okviru jednog app domena:

to je obicna aplikacija gde se svi elementi aplikacije ucitavaju u jedan app domen (u vb6 in-process), za razliku od npr: remoting-a gde su delovi aplikacije u razlicitim app domenima (zato se i koristi remoting -komunikacija objekata iz razlicith app domena).
Primer za slucaj 1: imas forme (GUI projekat) i imas business rules u jednom dll-u, pri tome taj dll refernciras iz GUI projekta. Pri startovanju tvoje GUI aplikacije u objekti iz busibess dll-a se ucitavaju u app domen GUI aplikacije.

pozdrav Željko
[ Toni_Spajic @ 02.02.2004. 16:58 ] @
Samo da utvrdim gradivo:
aplikacija može biti n-tier ako se slojevi
(bussines, pristup bazi,GUI) organiziraju u recimo
dll-ove, a svi ti dll-ovi se ( po potrebi) vrte u memoriji client-a,
u okviru istog application objecta (app domena)?

N-tier nije nešto što se nužno povezuje sa preraspodjelom
procesa između n mašina?


Ako imam thin client-a, a rich servera jedini
način da server 'podmetne leđa'
(za SQL već podmeće , ali za GUI,ili već šta .Net jede..)
za ovog tankog klijenta
jeste remoting?
[ degojs @ 02.02.2004. 18:19 ] @
Citat:
Pa, mašine su bedne sa pentium I procesorima. Nebitno mi je koliko će trebati da se aplikacija učita, bitno mi je da pristup dovoljno brzo radi, ali mašine su sa 32-64MB :(


Pa nemoj .NET onda ako imaš milosti.. Što ne uradiš VB6 ili C++ ?
[ Željko @ 02.02.2004. 19:03 ] @
Citat:

N-tier nije nešto što se nužno povezuje sa preraspodjelom
procesa između n mašina?

Obilje literature postoji o pravljenju n-tier aplikacija (jer to i nije tako nova stvar, n-tier aplikacije su se pravile i u vb4.0). Jedan primer n-tier aplikacije je da .exe (sama aplikacija) i ostali slojevi (business rules, data access layer) budu na istoj masini, to je onda 'logical n-tier model'.
Kada se govori o aplikacijama koje rade na vise masina onda se govori o distribuiranim aplikacijama (a one su uobicajeno i n-tier).
Pogledaj MSDN Building an N-Tier Application in .NET.

Citat:

Ako imam thin client-a, a rich servera jedini
način da server 'podmetne leđa'
(za SQL već podmeće , ali za GUI,ili već šta .Net jede..)
za ovog tankog klijenta
jeste remoting?


Osim remoting-a, mozes koristiti i web service. Takodje o tome imas u gore navedenom clanku u MSDN-u.

pozdrav Željko