Questôes sobre Multi-Camada, não acho de jeito nenhum...

Bom, normalmente um servidor de Banco de Dados é um .exe
Não sei te responder pq utilizo TServerSocket e TClientSocket
Em tres camadas vc elimina de vez os problemas de conexão via internet. Quanto ao DataSnap, eu não conheço pq utilizo Sockets nos Clients e Server.

Amigo IPC, como você utiliza o Socket? Pois eu soh sei utilizando o SocketConnection, com ScktSrvR.exe como servidor... fora o servidor do banco de dados...


[]s

Faz algum tempo que lidei com isso, mas achei bons exemplos no [url=http://distribucon.com/midas.html]site do Dan Miser[/url] (em inglês).

Quanto ao scktsrvr, no CodeCentral da Borland tem uma [url=http://codecentral.borland.com/Item.aspx?id=18265]versão não oficial[/url] do programa, mas parece que ela resolve um problema em máquinas com mais de um processador (para baixar o arquivo talvez você tenha que fazer login ou registrar-se gratuitamente no site da Borland).

Nesse caso como ficaria? Suponha que vc tenha 3 máquinas acessando o sistema, quantas conexões o Banco de Dados abre?

Bem, ele , pelo que eu sei, tem apenas uma conexao com o banco de dados... nao tenho certeza... irei ver os sites indicados pelo amigo massuda pra ver se consigo esclarecer minhs duvidas....

minha opiniao:

Se esta eh uma tecnologia boa, que dizem pro futuro, e já vem sendo desenvolvida deste o Delphi 5, porque nao encontramos nada dela? nem livro direito tem... será que vale a pena desenvolver um sistema em n-camadas?



[]s

Bom, não conheço a tecnologia a qual vc se refere, mas pelo que escrevo em 3 camadas, a aplicação Client fica livre dos componentes SQL e não tem mais nada a ver com o Banco de Dados, ficando isso por conta da aplicação servidora.
Nesse tipo de desenvolvimento existem muitas restrições para quem desenvolve em Client/Server pq muito dificilmente vc converte um Client/Server para 3 camadas sem ter que reprogramá-lo. Sou meio radical nesse ponto, ou vc fica com Client/Server, ou começa a desenvolver em 3 camadas a partir do zero. Quanto a valer a pena, a única desvantagem é para quem desenvolve, pq para quem usa só tem vantagens.

justamente isso... os meus tbm sao assim, o acesso ao banco fica no servidor, e nao no cliente.. tudo feito em n-camadas usando SocketConnection..


a questão é, que se fala muito em 3-camadas, que ela é o futuro e tals.. mas não se acha nada a respeito dela, soemnte poucos artigos, pouquissimos livros... aí eu me pergunto, será que realmente vale a pena desenvolver um sistema em 3 camadas?

Bom, escrevendo o sistema desde o início no final vale a pena pq vc tem a aplicação Client enxuta, livre dos componentes SQL e a aplicação servirdora se encarrega somente disso; ou seja; cada macaco no seu galho, o Client faz o que tem que fazer e o Server também. As coisas funcionam distintamente e o código muito mais limpo; já se vc converte um Client/Server para 3 camadas(nunca fiz), o código deve ficar uma salada.
Me diga uma coisa: nesse SocketConnection quando vc tem um cadastro com + 10.000 registros e o Client solicita um desfile num ListView por ex, como ele faz? Manda os 10.000 de uma vez ou parametriza?

Isso mesmo amigo, no caso eu estou criando um project do zero, partindo do zero mermo... no meu caso eu uso parametros pra trazer os dados do server, ou seja

select * from cliente
where cod_cliente = :PCod

ou seja soh traz um dados de uma vez... agora jah com o master/detail, eu trago do mesmo jeito, mas no caso ele tem mais registros.. mas eu sempre uso parametros...

No caso, o que voce usa no servidor? O aplicativo scktsrvr.exe da propria microsoft ou voce criou o seu?

digo, nao o servidor que tem o acesso ao banco de dados, mais sim o servidor que recebe a conexao Socket..


[]s

Acho que entendí, vc parametriza por comando SQL. No meu caso não; a aplicação Client pode solicitar a tabela inteira num grid porém é definido uma quantidade de registros limite para combos, grdis e relatórios; ou seja; o servidor só manda aquela qtde de registros e o Client possui botões de próximos, anteriores, início e fim.
Quanto ao servidor, utilizo Sockets para os Clients se conectarem e enviarem comandos. Basicamente o Server abre uma thread para cada cliente conectado, recebe o comando, processa e envia o resultado. O processamento é feito nas threads para evitar que um Client fique esperando o processamento do outro.

Certo amigo, mas no caso, o servidor do socket, vc desenvolveu um? ou usou o do proprio delphi?

Escreví utilizando TServerSocket no servidor e TClientSocket na aplicação cliente. Quase sempre o servidor fica na mesma máquina do Banco de Dados, é por isso que se elimina de vez os problemas de conexão intranet e internet.

a sakei, intaum vc desenvolveu um servidor de socket, pois eu utilizo o SrvSocktR.Exe da propria borland, porem estou tendo um problema com ela, quando uma conexao fica agarrada, aih o servidor meio que trava....

vc poderia me dar um exemplo como vc construiu o seu servidor de socket? Por acaso eh onde vc tbm tem as conexoes com o Banco de Dados, ou seja, eh onde vc tem as Querys e tals?


[]s

É, o programa servidor possui um TServerSocket que fica aberto numa determinada porta; quando um TClientSocket se conecta a ele, no evento onAccept, o servidor abre uma Thread para aquele cliente conectado e no método Execute desta Thread, fica na espera de comandos para serem processados. O servidor é responsável também pela conexão ao Banco de Dados e da criação de objetos TQuery, TSQLQuery, TIBQuery ou TIBClientDataSet, dependendo do modo de acesso, BDE, DBExpress ou IBX. O Client envia o comando, o servidor processa e retorna o resultado
na Thread responsável por aquele Client. Para isso vc tem que ter uma classe de manipulação e transporte de dados para comunicação entre clientes e servidor que sempre é feita através de Sockets.
No começo testei um pouco Corba, mas achei complicado e DCom só dava pau, então optei por escrever um servidor utilizando Sockets.

cara, chegamos aonde está meu problema.. :d

O meu sistema está sendo feito sobre a camada DCOM, por isso dá muito pau, vixi maria, mas eu nunca vi nada parecido sobre o Sockets, e acho q meu delphi não tem este componente, a não ser que ele não seja visual :D, pois procurei nas paletas e naão achei...

Mas você não teria nenhum site, artigo ou algo parecido que me explique o básico pra se criar um servidor socket pra n-camadas?

[]s

Bom, no Delphi 6 estão na paleta Internet, se for o Delphi 7, veja em:
http://bdn.borland.com/article/0,1410,29768,00.html
Se for outro Delphi, não saberei te dizer mas eles devem estar aí por razões de compatibilidade.

Quanto a artigos sobre Sockets, lembro que na época há uns 4 anos, apanhei muito com eles por falta de documentação e só conseguí prosseguir através do help e de pesquisas pela rede.

Opa, achei ele, eh o SocketServer mesmo.... estranho, mas como vc faz pra comunicar, tipo, como vincular o ClientDataSet no DataSetProvider lá no server?



[]s

Sockets não são específicos para 3 camadas, são apenas componentes para conexão e comunicação entre computadores. Utilizo este meio de comunicação para que, em cima disso, consiga escrever sistemas multi-camadas. A aplicação cliente não possui ClientDataSet ou qualquer outro componente SQL, apenas se conecta ao servidor, envia comandos e recebe o resultado. É bom lembrar que neste tipo de desenvolvimento, não existe nada pronto, vc tem que escrever tudo.

vixi.. entao vc cria um DataSet? Caraca, ainda não é pra mim... ainda passo maior raiva com o CDS :D, é mais eu queria mesmo era sair da porcaria do DCOM, ele tá travando muito no meu cliente...

Só a título de curiosidade, você já viu o sistema da MicroSiga? o Protheus? Ele é feito em 3 camadas também, como será que eles fazem?



[]s

No lado cliente não; eles são criados no lado servidor na medida que ele for precisando.Já ouví falar da MicroSiga mas não conheço seus sistemas. Acredito que em qualquer caso, não tem jeito, vc tem que escrever seu servidor. Empresas que possuem equipes de desenvolvimento, normalmente escrevem uma quarta camada chamada de servidor de aplicação, onde colocam todas suas regras de negócio e também possuem servidores-backup para no caso de uma máquina pifar, seu backup entrar em operação. Mas isso tudo requer tempo e investimento; no meu caso as regras de negócio ainda estão na camada cliente.

Blz amigo, mas tipo... como você vincula os dados no servidor? Voce Utiliza DBEdits e tals? Bem, acho que não né, :d pois não tem DataSet.... então como voce faz isso? Cria um Edit normal, e uma funcao que enviar os dados dele pro servidor?



[]s

Bom, suponha uma manutenção de cadastro. O Client solicita ao Server um cursor de dados, o Server, na Thread relativa àquele Client conectado, instancia um Dataset(se não houver nenhum disponível), dá um Select e manda esse cursor de dados ao Cliente, parametrizando a quantidade de registros para aquela tabela. O Client recebe a informação e continua seu processamento normalmente.

Certo, mas como vc exibirá isso ao usuário, através de Edits?

Para dlls de manutenção utilizo um componente chamado DataInspector da suite InfoPower, vc pode achá-lo em www.woll2woll.com
Ele é bastante flexível; possui células de título, caption e dados; vc pode dispor os dados por assunto em estrutura de Treeviews; pode colocar WinControls em determinadas células e pode também ligá-lo a um Dataset.

Blz amigo, só outra perguntinha... vc citou DLL, pois bem, em cada DLL dessa tem uma conexao com o socket ]? ou vc tem um principal que as DLLs enchegam ele..?

A aplicação passa o Socket conectado para a dll; senão haveria outra conexão no servidor e consequentemente outras Threads abertas.

Entao suas DLL sao os ´modulos´ do sistema...

Como você ´passa´ a conexao para a DLL?


Vixi amigo, vc deve estar cheio de mim.. hehe... tantas perguntas.. :D

Isso mesmo, a aplicação cliente(.exe) se conecta ao servidor e dá uma interface amigável para o usuário final; o sistema em sí é executado nas dlls.

O parâmetro do Socket é passado por ponteiro, ou seja, quando o .exe chama uma função na dll, passa um type record de parâmetros e um deles é o ponteiro de TClientWinSocket.

Vixi, estamos chegando lá :D, acredito que este tópico seja o mais longo e de maior proveito sobre 3-camadas em delphi daqui do fórum, graças a sua ajuda,... :roll:

Mas, tipo, ele passa como ponteiro, certo... não teria como me mostrar um exemplo, se possível me enviar um exemplo básico disso aí? Só pra ter uma idéia... pois agora está formando uma idéia na cabeça :D:D

Acho que seria mais complicado de se entender pq esse ponteiro na dll é repassado na criação do objeto de transporte de dados(aquele que efetivamente se comunica com o servidor).
Se vc quiser utilizar Sockets, comece com dois programas, Server e Client; veja os eventos onAccept, onClientRead, onClientDisconnect e onClientError no Server. No Client veja onLookup, on Connecting, onConnect, onRead, onDisconnect e onError. Teste os comandos SendText e ReceiveText, quando estiver legal, teste os comandos SendBuf e ReceiveBuf pq é isso que terá que usar para troca de dados. Quando vc dominar o transporte de buffers, Faça isso em Threads abrindo uma para cada Client conectado: Crie uma classe que descenda de TThread e coloque um TCustomWinSocket em seu construtor.
Bom, acho que isso seria o básico para começar; o próximo passo acredito que seria vc criar um objeto de transporte para ser utilizado tanto no Server quanto no Client.
Como vê, vc tem que escrever tudo. Hoje em dia deve ter ferramentas que otimizem bastante esse trabalho, mas eu não conheço pq para mim seria algo inviável.

Espero ter ajudado !!!

realmente, terei que escrever muita coisa.... :D, então é mãos a obra... obrigado amigo...


[]s

Como vc faz pra mandar varios registros de um relatorio por exemplo?
Num pode ser via sendtext que tem a limitacao da string(255 caracteres).

Na verdade (pelo menos na forma que eu implementei) o SendText apenas envia o texto, que seria uma flag para indicar que o os dados estão sendo enviados. Eu fiz assim, armazeno o resultado (os campos com seus valores), em um Stream, e então envio a flag <data> pelo sendstream, dessa forma, o cliente se prepara para receber dados, e após o termino do envio dos dados (stream), envio a flag </data> para indicar que terminou o envio dos dados. Dessa forma, se houver algum erro no envio dos dados, ou seja, se a conexão cair ou coisa assim, os dados não são gravados, e é retornada uma exceção indicando a perda de comunicação.

Agora, colega titanius, como forma de aproveitar tudo o que você já tem pronto, você poderia usar SOAP para criação de sua camada intermediária. Assim não precisaria se preocupar com a implementação de todos os métodos (como o colega IPC$ fez, e eu também). A implementação é bem simples, e você pode usar o IIS ou Apache para distribuir os objetos. É muito bom, tanto com relação ao desempenho, quanto em relação a simplicidade de desenvolvimento. Ou também, dê uma olhada sobre MTS (Microsoft Transaction ..., não me lembro direito do significado). Ele consiste na utilização de Transaction Data Modules no lugar de Remote data Modules, e sua publicação através do IIS (mesmo conceito aplicado quando se usa SOAP, porém se restringe ao Windows). No caso do SOAP você poderia ter sua camada intermediária em um servidor que utiliza Linux (apesar de ter que recompila-lo no Kylix). Mas enfim, acho uma boa saída para que você não tenha que refazer todo o trabalho.

Toda informação, tanto do lado Client quanto do lado Server é enviada através de um objeto de transporte de dados. O comando de envio do Socket é o SendBuf mandando um PChar de memória contínua com os bytes necessários. Diferentemente dos flags de início/fim que o colega Firekiller utiliza, no meu caso, envio nos primeiros 4 bytes(Integer) o tamanho do que virá a seguir; com isto o lado que recebe, sabe através destes 4 bytes o que terá de ler em seguida.

[b:ec736d90e8]firekiller[/b:ec736d90e8] e [b:ec736d90e8]ipc$[/b:ec736d90e8] pelo que parece vcs trabalham com metodos similares mas diferentes, mas nao tenho a menor ideia de como funcionam. Por favor me mandem algum exemplo ou dica.
To desenvolvendo um projeto muito legal, a principio pegando informacao de SPC direto do meu sistema e numa segunda fase replicando informacoes de varios clientes em um unico servidor.

Mas ja agradeco pelas informacoes. Estou priorizando esse projeto.