Dette faget var opprinnelig et svar til Peter Morris "N-tier" nyhetsgruppe tråden, men jeg starter en ny tråd her på temaet DCOM for andre lurer på om DCOM.
Spørsmål og bekymringer om ", problemer med BoldCOM " blir hørt i nyhetsgrupper og jeg her ønsker å gi noen hint.
Først vil jeg anbefale å variere typiske problemer ved hjelp av en vanlig CPU for å betjene flere klienter fra " protokollen " (Og relaterte triks) koble kunder til CPU (Mer om det i sammendraget langt under).
Noen skjermbilder visualiserer noen simplier løsninger på noen spesifikk " DCOM UI komponent problem " forårsaket av Fet komponenter som abonnerer på enkelte felt av enkeltobjekter over et nettverk (eller enda verre, over internett ...). Enhver overføringsprotokoll vil i en flerbruker miljø nå noen tilstede dag båndbredde grenser prøver å gjøre det uten omsorg. Men hvis det brukes med forsiktighet og designe hele miljøet (server & klient) for å støtte en tre lags " protokollen løsning " Fet DCOM løsningen har også sine fordeler.
Se på skjermbildene nedenfor og prøve å forestille seg hva som er bak kulissene, å huske at ingen forretningslogikk eksisterer på klientsiden, finnes det ingen logikk i databasen, alt utført på en (1) server CPU i samspill med flere klienter. Den viser også at en RAD DCOM UI ikke behøver å være fattig, 100% statsløse og " døde " til brukeren. Faktisk kan det være ganske " befolket " og tilsynelatende svært aktiv og svarer til brukeren. Med Bold DCOM kan DU avgjøre " stateness " av de data som overføres mellom server og klient. Du kan variere din tilnærming og UI løsninger avhengig av hyppigheten av bruk, CPU belastning forårsaket av enkle tiltak, og behovet for " aktivt samspill " og støtte av alternative data vises. Alt dette avhengig av detaljer i brukerhandlinger og skiftende sammenhenger i redigerings dialoger etc. Har denne frihet søkeordene er " variere " og " mulig " om teknikker. Disse søkeordene gjelder fordi du har en nesten komplett spekter av tekniske og funksjonelle muligheter selv om du ikke alltid har ubegrenset kapasitet (båndbredde etc). Dermed må du variere din tilnærming.
ha sagt alt dette, minner deg på at skjemaet nedenfor er en fullt funksjonell i sin endelige RT miljø (DCOM klienter i Metaframe), kan se på skjermbilder,
Tre skjermbilder som viser data i " seere " i stedet for å vise enkeltobjektmedlemmer ved hjelp av separate DCOM komponenter for hvert attributt. (Merk også at de fleste av liste håndtakene brukes bare når utløser leteaksjoner på etterspørsel, de er vanligvis ganske passive når bare ser på & nettleserdata med form)
Fig 1: Bestill bokform (pakker for senere transport planlegging) design tid - skjemaet ser ganske " tom " i design tid (= mange blank HTML seere):
Figur 2: ... i runtime brukergrensesnittet er fullt informativ og interaktiv.
Ved å klikke på HTML betrakteren av " Parcel Detaljer " åpner en vanlig dialog med Delphi komponenter (ikke Fet klar). På bekrefte dataene sendes til serveren som setter detaljene i passende objekt felt forårsaker UI attributtet 'ParcelDetailsAsHTML' for å oppdatere visningen ved å sende en eneste ny (html) strengen tilbake til klienten. Bruker meldinger blir vist som feil, advarsler eller informasjon til høyre ved hjelp av symboler, klient unik bruker språket i html formatert tekst (eller vanlig strenger fra kode påstander eller andre kodemeldinger). Form bildetekster og data og datalabels blir vist på det språket definert av brukeren. Den samme server funksjonen returnerer tekst på forskjellige språk, avhengig av " som ber ". Språk kan endres i runtime (ikke fullt implementert på dette skjemaet selv, du ser både svensk og engelsk blandes her, pluss noen feilsøkingsverktøy i øvre høyre hjørne for surfing og manipulere alt fra fet klassemedlemmer til meta data, stater, manipulere staten overganger, krysser den aktuelle objektet struktur, sending /mottak av intra-klient chat, ditto post og mer, kort tid - alt (Merk - dette kalles en " tynn " DCOM-klient)
figur 3 Her kan du. se resultatet av forrige dialogboks sendt til OSP og umiddelbart analyseres tilbake til klienten som en (1) html streng for betrakteren (til høyre for den nye dialogboksen nedenfor). En rask og enkelt konsept.

Endelig - fig 3 viser et eksempel på en vanlig html hyperkobling utløser en hendelse som bestemmer hvilken dialog og hvilke data (siden flere partys er stablet i egne seere til venstre) for å samle /skal vises i dialogboksen Disse feltene. er veldig spesiell i at de er passiv viser data, men samtidig aktivt i stand til å søke etter data over DCOM og dermed de er " aktiv on demand ". Men denne aktiviteten har en relativt lav frekvens, og de er svært midlertidig og dermed ikke påvirke ytelsen veldig mye - Vise og surfing data er hva metter nettverket! (Hyper koblinger er " språk sensitive " før vi fullt implementert dette på cleint side siden html tekst genereres av OSP serveren og dermed vist i min bruker språk - svensk).
Oppsummering
All den enkelte datafeltene som vises i disse eksemplene hvor " passive mens synlig ". Gule COM-komponenter ble kun brukt til å hente biter av gruppert datafelt som lange strenger og sendt tilbake igjen etter dialoger ble stengt (med unntak av rutenettet som trolig vil bli erstattet senere fordi dette er et hot spot form i Attracs).
Datavalidering er 100% validert av forretningsregler på tjenersiden (ingen forretningslogikk finnes i klienten).
Med denne tilnærmingen til å blande begrepene " aktiv " COM håndterer og " passiv " html strykere brukeren opplever en " aktiv " UI men teknisk sett er det nesten " stein død ". Ingenting faktisk happends unntak for vanlig format sjekker i dialogfelt og sende data tilbake til server logikk. Oppsiden er at de gule handlers er forfriskende seerne med den siste aktuelle html data ved hjelp av vanlige Fet abonnement mekanisme (Merk at de fleste subcriptions vil være på serverside siden html-attributtet holder styr på de mange felt internt på serverside, men bare ett felt per seer har abonnement over DCOM).
Siden bildetekster og etiketter i html-tekst er språkfølsomme vi har i kraft mange hundre " pseudo aktive " datafelter på dette skjemaet ...! (Sett fra serversiden). Betrakteren tilnærming reduserer det store antallet ned til en brøkdel, og brukergrensesnittet er i realiteten ikke " treg " i det hele tatt selv ved hjelp av en vanlig nettverkstilkobling. Med mange brukere (10+) en Metaframe løsning ville redusere ytelsesproblemer på nettverket til nesten " ingenting ".
Server ytelse
Kanskje en kan bli blandet opp om " ytelsesproblemer med DCOM " og det faktum at en DCOM løsning innebærer anvendelse av en vanlig CPU som en applikasjonstjener. Merk at sistnevnte er knyttet til ytelsesproblemet, men ikke en eksplisitt DCOM problem - effektiv design og koding er et must for enhver løsning ved hjelp av en felles Application Server.
Effektiv koding alene er definitivt ikke nok. Kombinerer design & skarp koding vil gjøre selv, en må " tenke effektive løsninger /konsepter " fra selve modellen og holde den for den generelle design hele veien tilbake og fjerde til klientene. Dette er viktig, og vi har lært mye rett og slett fordi vi ble tvunget til, vi brukte en enkelt * FELLES CPU * på app serversiden.
Sette alt sammen det ser ikke så ille med Fet DCOM løsning så vidt jeg kan se. Ved hjelp av det å være klar over " sine grenser " (Båndbredde for detaljerte gjenstander attributter, bruker triks for å redusere en rekke objekter i oppføringer osv) så det handler om deg. Det er kraftig hvis det brukes med forsiktighet. Dens ubrukelig hvis design og programmet ikke er tilrettelagt for det.
slutt
Da vi begynte å bruke Fet DCOM teknikken det var buggy og treg, og det var åpenbart at det var " umulig " for å oppnå den nødvendige ytelse og pålitelighet. Å være sta og litt gal, og Boldsoft fikse bugs og noen optimaliseringer, og søtningsstoffer det hele med litt tålmodighet - og løse grunnleggende problemer allerede i modellen (unngå koding triks) - det ser helt annerledes i dag. For meg ser det lovende ut. En talentfull designer løser eventuelle flaskehalser og noen typiske ytelsesproblemer i en eller annen måte.
Nye tanker og never_seen_before_solutions er noen ganger (ofte) som kreves, men er ikke det hva designere er bra for likevel? &Quot; Modellen er systemet " gjelder for BoldCOM også.
Systemer med mange brukere vil ha nytte av å kjøre klienter i et Metaframe miljø.
//Rolf Lampa product: (Nåværende postadresse: rolf-dot-lampa-at-rilnet-dot-com)