Aqui na empresa a comunicação e feita pelo Fluorine e o backend é .Net

Em 18 de outubro de 2013 11:56, Hugo Ferreira <[email protected]>escreveu:

> A nível do PHP recomendo usares Codeigniter (se não é que não estás a usar
> :)) que ele já te disponibilizar um ORM que uma perfomance decente.
>
> Eu basicamente quando preciso de criar a gestão de uma nova tabela, crio o
> VO no backend (e mais absolutamente mais nada), o VO no frontend (no model,
> claro), + manager + view e então se fizer sentido, lógica de negócio no meu
> manager (sim é onde faço e para mim onde faz sentido :))
>
>
> No dia 18 de Outubro de 2013 às 11:48, João Fernandes <
> [email protected]> escreveu:
>
> O ideal será sempre fazer profiling tanto à parte do front-end como do
>> backend para se identificar onde se encontram os blocos mais lentos. Por
>> exemplo em AMF, o ideal é devolver colecções de registos em Arrays em vez
>> de ArrayCollections, principalmente se existirem multiplos níveis de
>> hierarquia pois a deserialização de VOs mesmo que seja rápido no Flash
>> Player, quando são arrayCollections, estes terão de inicializar sempre o
>> seu processo de listeners, criar UIDs para os elementos etc. Nós em certas
>> áreas passamos de respostas de 3s para colecções muito pesadas para menos
>> de 200ms.
>>
>> A nivel do PHP não sei que ferramentas poderás encontrar mas no que diz
>> respeito ao Flash podes (e deves) usar o Scout. Este dá-te informação
>> detalhada e consegues encontrar rapidamente a origem dos problemas.
>>
>>
>> 2013/10/18 Hugo Ferreira <[email protected]>
>>
>>> Então esses delays poderão não estar ao nível do amfphp mas sim a nível
>>> da tua lógica de backend ou mesmo BD.
>>>
>>> Tenho um caso em que o utilizador pressiona um botão numa app e é
>>> efectuado um pedido que tem de passar pelo meu backend (com amfphp) e ir a
>>> outra máquina via web services e tem de ser o mais rápido possível porque a
>>> lógica de negócio assim o exige. Se demorar mais de 3 segundos inviabiliza
>>> totalmente a após centenas de testes efectuados é sempre instantaneo (nunca
>>> chega a 1 segundo). Também estou a falar de servidores de topo, claro.
>>>
>>>
>>>
>>>
>>>
>>> No dia 18 de Outubro de 2013 às 11:37, Miguel Vaz 
>>> <[email protected]>escreveu:
>>>
>>>
>>>> Também tenho problemas de performance com a 2.x, estranhamente, mas
>>>> mesmo com a 1.9 tenho alguns delays que não consigo identificar. De
>>>> qualquer forma, estou disposto a mudar seja para o que for se aumentar a
>>>> performance.
>>>>
>>>> Miguel
>>>>
>>>>
>>>> 2013/10/18 Hugo Ferreira <[email protected]>
>>>>
>>>>> Bom dia,
>>>>>
>>>>> Eu utilizo amfphp 1.9 (legacy). Quando a versão 2 saiu, fui logo
>>>>> testar e teve problemas de performance.
>>>>> A versão 1.9 tinha um problema com datas que eu corrigi do meu lado
>>>>> mas de resto serve muito bem o seu prepósito e cria o mínimo de 
>>>>> resistência
>>>>> no processo.
>>>>>
>>>>> Em .NET usei fluorinefx.
>>>>>
>>>>>
>>>>> No dia 18 de Outubro de 2013 às 11:28, Miguel Vaz <[email protected]
>>>>> > escreveu:
>>>>>
>>>>>> Bom dia,
>>>>>>
>>>>>> Considerando a thread anterior, que mostra que ainda existem pelo
>>>>>> menos uns 12 programadores em flex, qual é a vossa opinião/experiência 
>>>>>> com
>>>>>> comunicação flex<->BD(mysql,postgresql, etc)?
>>>>>>
>>>>>> tenho utilizado amfphp e weborb como interface entre a base de dados
>>>>>> e as aplicações flex, mas não estou completamente satisfeito com as
>>>>>> velocidades de resposta.
>>>>>>
>>>>>> Se não existirem condicionantes de tempo, servidor, qual é a
>>>>>> tecnologia mais rápida para este efeito? Há uns anos participei num
>>>>>> projecto em que essa comunicação assentava num tomcat+java e a resposta 
>>>>>> era
>>>>>> extremamente rápida, ainda há alguém que utilize este par?
>>>>>>
>>>>>> Muito obrigado.
>>>>>>
>>>>>> Miguel Vaz
>>>>>>
>>>>>> --
>>>>>> Recebeu esta mensagem porque está inscrito no grupo "Mailing List da
>>>>>> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org"
>>>>>> dos Grupos do Google.
>>>>>>
>>>>>> Para anular a subscrição deste grupo e parar de receber emails deste
>>>>>> grupo, envie um email para [email protected].
>>>>>> Para publicar uma mensagem neste grupo, envie um e-mail para
>>>>>> [email protected].
>>>>>> Visite este grupo em http://groups.google.com/group/riapt.
>>>>>> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>>>>>>
>>>>>
>>>>>  --
>>>>> Recebeu esta mensagem porque está inscrito no grupo "Mailing List da
>>>>> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org"
>>>>> dos Grupos do Google.
>>>>>
>>>>> Para anular a subscrição deste grupo e parar de receber emails deste
>>>>> grupo, envie um email para [email protected].
>>>>> Para publicar uma mensagem neste grupo, envie um e-mail para
>>>>> [email protected].
>>>>> Visite este grupo em http://groups.google.com/group/riapt.
>>>>> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>>>>>
>>>>
>>>>  --
>>>> Recebeu esta mensagem porque está inscrito no grupo "Mailing List da
>>>> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org"
>>>> dos Grupos do Google.
>>>>
>>>> Para anular a subscrição deste grupo e parar de receber emails deste
>>>> grupo, envie um email para [email protected].
>>>> Para publicar uma mensagem neste grupo, envie um e-mail para
>>>> [email protected].
>>>> Visite este grupo em http://groups.google.com/group/riapt.
>>>> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>>>>
>>>
>>>  --
>>> Recebeu esta mensagem porque está inscrito no grupo "Mailing List da
>>> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org"
>>> dos Grupos do Google.
>>>
>>> Para anular a subscrição deste grupo e parar de receber emails deste
>>> grupo, envie um email para [email protected].
>>> Para publicar uma mensagem neste grupo, envie um e-mail para
>>> [email protected].
>>> Visite este grupo em http://groups.google.com/group/riapt.
>>> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>>>
>>
>>
>>
>> --
>>
>> João Fernandes
>>
>> --
>> Recebeu esta mensagem porque está inscrito no grupo "Mailing List da
>> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos
>> Grupos do Google.
>>
>> Para anular a subscrição deste grupo e parar de receber emails deste
>> grupo, envie um email para [email protected].
>> Para publicar uma mensagem neste grupo, envie um e-mail para
>> [email protected].
>> Visite este grupo em http://groups.google.com/group/riapt.
>> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>>
>
>  --
> Recebeu esta mensagem porque está inscrito no grupo "Mailing List da
> Comunidade Portuguesa de Rich Internet Applications - www.riapt.org" dos
> Grupos do Google.
>
> Para anular a subscrição deste grupo e parar de receber emails deste
> grupo, envie um email para [email protected].
> Para publicar uma mensagem neste grupo, envie um e-mail para
> [email protected].
> Visite este grupo em http://groups.google.com/group/riapt.
> Para mais opções, consulte https://groups.google.com/groups/opt_out.
>

-- 
Recebeu esta mensagem porque está inscrito no grupo "Mailing List da Comunidade 
Portuguesa de Rich Internet Applications - www.riapt.org" dos Grupos do Google.

Para anular a subscrição deste grupo e parar de receber emails deste grupo, 
envie um email para [email protected].
Para publicar uma mensagem neste grupo, envie um e-mail para 
[email protected].
Visite este grupo em http://groups.google.com/group/riapt.
Para mais opções, consulte https://groups.google.com/groups/opt_out.

Responder a