estou desenvolvendo um projeto para funcionar como SaaS, é um projeto pessoal e por esse motivo posso decidir o que fazer nele sem problemas de custo (até parece) e de prazo.
O que imaginei é o seguinte:
ASP.NET MVC (testei nos últimos dias e realmente é interessante)
WCF RESTFul
DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
SQLServer 2008.
Em que pé está?
Bem, o modelo está bem adiantado com o domínio quase todo implementado (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos repositórios (apenas 1 real implementado pra testar o NH com o FluenteNH)).
Somente para testar conceito implementei um webform pra falar com o domínio e o repositório real (não tem WCF no caminho) pra testar o conceito e testar a Transação do NH através do IHTTPModule. Está tudo funcionando... mas aí começam as minhas dúvidas em que caminho seguir, então vms lá.
1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON (dentro de uma conexão HTTPS) 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a camada de aplicação... 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma fachada chamando os métodos de aplicação e esse sim seria responsável por processar o pedido e encaminhar a requisição a quem for de direito.
Primeira dúvida:
Já que terei o WCF onde devo chamar a transação do NH? Não usarei o IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a transação na camada de aplicação somente nos métodos onde houvesse add, merge e remove. Essa é uma boa decisão? E se for boa, não consegui imaginar uma solução pra automatizar a criação deste contexto teria que repetir esta chamada em cada método e isso não me agrada(o que no IHTTPModule eu tenho de forma automática no Init).
Segunda dúvida:
Onde devo criar o Json? na camada de aplicação ou WCF? Tinha pensado em cria métodos utilitários de transformação de obj pra json e usá-los na camada de aplicação. e este iria responder pra quem solicita-se o JSON. Isso não me agrada, pois estaria fazendo a minha aplicação ter uma responsabilidade tecnológica (JSON) e se depois eu quisesse mudar a abordagem ou acoplar uma outra interface (UI) que não fosse WCF eu teria que reescrever código ou mesmo duplicar.
Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o conhecimento do modelo pra fazer a transformação e eu não quero isso. Então pensei em um TO mas na minha visão estaria duplicando o modelo e tirando apenas dele o comportamento. Alguém tem alguma sugestão?
E por último o que acha da arquitetura de uma maneira geral.
A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a parada bombar mesmo a idéia é começar a vender pra empresas tb.
Com Hardware estou adquirido um servidor na DELL e vou fazer colocation com LINK de 20MBs.
Esta arquitetura é escalável? é uma boa abordagem?
Se você vai usar MVC, você pode responder em xml ou json sem problemas e vc tem os principais verbos http tambem disponiveis.
Quanto a transação do NHibernate, de acordo com o Ayende, TODA operação de escrita ou leitura deve ter uma transação, então fica fácil decidir onde colocar.
Att., Tuca
On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote:
> estou desenvolvendo um projeto para funcionar como SaaS, é um projeto > pessoal e por esse motivo posso decidir o que fazer nele sem problemas de > custo (até parece) e de prazo.
> O que imaginei é o seguinte:
> ASP.NET MVC (testei nos últimos dias e realmente é interessante)
> WCF RESTFul
> DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> SQLServer 2008.
> Em que pé está?
> Bem, o modelo está bem adiantado com o domínio quase todo implementado > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > repositórios (apenas 1 real implementado pra testar o NH com o FluenteNH)).
> Somente para testar conceito implementei um webform pra falar com o domínio > e o repositório real (não tem WCF no caminho) pra testar o conceito e testar > a Transação do NH através do IHTTPModule. Está tudo funcionando... mas aí > começam as minhas dúvidas em que caminho seguir, então vms lá.
> 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON (dentro de > uma conexão HTTPS) > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > camada de aplicação... > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma fachada > chamando os métodos de aplicação e esse sim seria responsável por processar > o pedido e encaminhar a requisição a quem for de direito.
> Primeira dúvida:
> Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > transação na camada de aplicação somente nos métodos onde houvesse add, > merge e remove. Essa é uma boa decisão? E se for boa, não consegui imaginar > uma solução pra automatizar a criação deste contexto teria que repetir esta > chamada em cada método e isso não me agrada(o que no IHTTPModule eu tenho de > forma automática no Init).
> Segunda dúvida:
> Onde devo criar o Json? na camada de aplicação ou WCF? > Tinha pensado em cria métodos utilitários de transformação de obj pra json > e usá-los na camada de aplicação. e este iria responder pra quem solicita-se > o JSON. Isso não me agrada, pois estaria fazendo a minha aplicação ter uma > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar a > abordagem ou acoplar uma outra interface (UI) que não fosse WCF eu teria que > reescrever código ou mesmo duplicar.
> Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > conhecimento do modelo pra fazer a transformação e eu não quero isso. Então > pensei em um TO mas na minha visão estaria duplicando o modelo e tirando > apenas dele o comportamento. Alguém tem alguma sugestão?
> E por último o que acha da arquitetura de uma maneira geral.
> A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a parada > bombar mesmo a idéia é começar a vender pra empresas tb.
> Com Hardware estou adquirido um servidor na DELL e vou fazer colocation > com LINK de 20MBs.
> Esta arquitetura é escalável? é uma boa abordagem?
> Se você vai usar MVC, você pode responder em xml ou json sem problemas > e vc tem os principais verbos http tambem disponiveis.
> Quanto a transação do NHibernate, de acordo com o Ayende, TODA > operação de escrita ou leitura deve ter uma transação, então fica > fácil decidir onde colocar.
> Att., > Tuca
> On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote: > > Vms lá!
> > estou desenvolvendo um projeto para funcionar como SaaS, é um projeto > > pessoal e por esse motivo posso decidir o que fazer nele sem problemas de > > custo (até parece) e de prazo.
> > O que imaginei é o seguinte:
> > ASP.NET MVC (testei nos últimos dias e realmente é interessante)
> > WCF RESTFul
> > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > SQLServer 2008.
> > Em que pé está?
> > Bem, o modelo está bem adiantado com o domínio quase todo implementado > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > repositórios (apenas 1 real implementado pra testar o NH com o > FluenteNH)).
> > Somente para testar conceito implementei um webform pra falar com o > domínio > > e o repositório real (não tem WCF no caminho) pra testar o conceito e > testar > > a Transação do NH através do IHTTPModule. Está tudo funcionando... mas aí > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON > (dentro de > > uma conexão HTTPS) > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > > camada de aplicação... > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma > fachada > > chamando os métodos de aplicação e esse sim seria responsável por > processar > > o pedido e encaminhar a requisição a quem for de direito.
> > Primeira dúvida:
> > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > transação na camada de aplicação somente nos métodos onde houvesse add, > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui > imaginar > > uma solução pra automatizar a criação deste contexto teria que repetir > esta > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu tenho > de > > forma automática no Init).
> > Segunda dúvida:
> > Onde devo criar o Json? na camada de aplicação ou WCF? > > Tinha pensado em cria métodos utilitários de transformação de obj pra > json > > e usá-los na camada de aplicação. e este iria responder pra quem > solicita-se > > o JSON. Isso não me agrada, pois estaria fazendo a minha aplicação ter > uma > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar a > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF eu teria > que > > reescrever código ou mesmo duplicar.
> > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > > conhecimento do modelo pra fazer a transformação e eu não quero isso. > Então > > pensei em um TO mas na minha visão estaria duplicando o modelo e tirando > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > E por último o que acha da arquitetura de uma maneira geral.
> > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a parada > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > Com Hardware estou adquirido um servidor na DELL e vou fazer colocation > > com LINK de 20MBs.
> > Esta arquitetura é escalável? é uma boa abordagem?
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
Pensei em WCF pq se no futuro quiser ter uma implementação diferente (mas que fosse HTTP) para um cliente específico, não teria um projeto diferente e sim uma interface (UI) diferente pra cada projeto.
Tb me lembro de ter passado o olho neste post do Ayende, não lembro o pq desta afirmação, vc tem esse post aí( estou procurando se achar posto aqui)
> Se você vai usar MVC, você pode responder em xml ou json sem problemas > e vc tem os principais verbos http tambem disponiveis.
> Quanto a transação do NHibernate, de acordo com o Ayende, TODA > operação de escrita ou leitura deve ter uma transação, então fica > fácil decidir onde colocar.
> Att., > Tuca
> On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote:
> > Vms lá!
> > estou desenvolvendo um projeto para funcionar como SaaS, é um projeto > > pessoal e por esse motivo posso decidir o que fazer nele sem problemas de > > custo (até parece) e de prazo.
> > O que imaginei é o seguinte:
> > ASP.NET MVC (testei nos últimos dias e realmente é interessante)
> > WCF RESTFul
> > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > SQLServer 2008.
> > Em que pé está?
> > Bem, o modelo está bem adiantado com o domínio quase todo implementado > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > repositórios (apenas 1 real implementado pra testar o NH com o FluenteNH)).
> > Somente para testar conceito implementei um webform pra falar com o domínio > > e o repositório real (não tem WCF no caminho) pra testar o conceito e testar > > a Transação do NH através do IHTTPModule. Está tudo funcionando... mas aí > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON (dentro de > > uma conexão HTTPS) > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > > camada de aplicação... > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma fachada > > chamando os métodos de aplicação e esse sim seria responsável por processar > > o pedido e encaminhar a requisição a quem for de direito.
> > Primeira dúvida:
> > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > transação na camada de aplicação somente nos métodos onde houvesse add, > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui imaginar > > uma solução pra automatizar a criação deste contexto teria que repetir esta > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu tenho de > > forma automática no Init).
> > Segunda dúvida:
> > Onde devo criar o Json? na camada de aplicação ou WCF? > > Tinha pensado em cria métodos utilitários de transformação de obj pra json > > e usá-los na camada de aplicação. e este iria responder pra quem solicita-se > > o JSON. Isso não me agrada, pois estaria fazendo a minha aplicação ter uma > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar a > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF eu teria que > > reescrever código ou mesmo duplicar.
> > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > > conhecimento do modelo pra fazer a transformação e eu não quero isso. Então > > pensei em um TO mas na minha visão estaria duplicando o modelo e tirando > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > E por último o que acha da arquitetura de uma maneira geral.
> > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a parada > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > Com Hardware estou adquirido um servidor na DELL e vou fazer colocation > > com LINK de 20MBs.
> > Esta arquitetura é escalável? é uma boa abordagem?
Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil igual.
Juan,
nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC responde em qquer formato e WCF possui JSonSerializer também pra responder direto em Json.
Att., Tuca
On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote:
> Pensei em WCF pq se no futuro quiser ter uma implementação diferente > (mas que fosse HTTP) para um cliente específico, não teria um projeto > diferente e sim uma interface (UI) diferente pra cada projeto.
> Tb me lembro de ter passado o olho neste post do Ayende, não lembro > o pq desta afirmação, vc tem esse post aí( estou procurando se achar > posto aqui)
> On 3 fev, 17:09, tucaz <tuca...@gmail.com> wrote:
> > Henrique, pra que WCF?
> > Se você vai usar MVC, você pode responder em xml ou json sem problemas > > e vc tem os principais verbos http tambem disponiveis.
> > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > operação de escrita ou leitura deve ter uma transação, então fica > > fácil decidir onde colocar.
> > Att., > > Tuca
> > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote:
> > > Vms lá!
> > > estou desenvolvendo um projeto para funcionar como SaaS, é um projeto > > > pessoal e por esse motivo posso decidir o que fazer nele sem problemas de > > > custo (até parece) e de prazo.
> > > O que imaginei é o seguinte:
> > > ASP.NET MVC (testei nos últimos dias e realmente é interessante)
> > > WCF RESTFul
> > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > SQLServer 2008.
> > > Em que pé está?
> > > Bem, o modelo está bem adiantado com o domínio quase todo implementado > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > > repositórios (apenas 1 real implementado pra testar o NH com o FluenteNH)).
> > > Somente para testar conceito implementei um webform pra falar com o domínio > > > e o repositório real (não tem WCF no caminho) pra testar o conceito e testar > > > a Transação do NH através do IHTTPModule. Está tudo funcionando... mas aí > > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON (dentro de > > > uma conexão HTTPS) > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > > > camada de aplicação... > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma fachada > > > chamando os métodos de aplicação e esse sim seria responsável por processar > > > o pedido e encaminhar a requisição a quem for de direito.
> > > Primeira dúvida:
> > > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > > transação na camada de aplicação somente nos métodos onde houvesse add, > > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui imaginar > > > uma solução pra automatizar a criação deste contexto teria que repetir esta > > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu tenho de > > > forma automática no Init).
> > > Segunda dúvida:
> > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > Tinha pensado em cria métodos utilitários de transformação de obj pra json > > > e usá-los na camada de aplicação. e este iria responder pra quem solicita-se > > > o JSON. Isso não me agrada, pois estaria fazendo a minha aplicação ter uma > > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar a > > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF eu teria que > > > reescrever código ou mesmo duplicar.
> > > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > > > conhecimento do modelo pra fazer a transformação e eu não quero isso. Então > > > pensei em um TO mas na minha visão estaria duplicando o modelo e tirando > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > E por último o que acha da arquitetura de uma maneira geral.
> > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a parada > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > Com Hardware estou adquirido um servidor na DELL e vou fazer colocation > > > com LINK de 20MBs.
> > > Esta arquitetura é escalável? é uma boa abordagem?
Por que quando o usuário chama /Users/Details/1, decidir se isso vai ser respondido em HTML ou em JSON não é responsabilidade da camada de negócio, e sim da de user interface.
No Rails, por exemplo, existe um mecanismo padrão para escolha de formatters. Geralmente, "/Users/Details/1" responde HTML e "/Users/Details/1.json" responde JSON, por decisão do Controller, em uma sintaxe como:
respond_to do |format| format.html format.xml { render :xml => @user } format.json { render :json => @user } end
> Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil igual.
> Juan,
> nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por > meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC responde > em qquer formato e WCF possui JSonSerializer também pra responder > direto em Json.
> Att., > Tuca
> On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote: > > Opa vlw TUCAZ!
> > Pensei em WCF pq se no futuro quiser ter uma implementação diferente > > (mas que fosse HTTP) para um cliente específico, não teria um projeto > > diferente e sim uma interface (UI) diferente pra cada projeto.
> > Tb me lembro de ter passado o olho neste post do Ayende, não lembro > > o pq desta afirmação, vc tem esse post aí( estou procurando se achar > > posto aqui)
> > On 3 fev, 17:09, tucaz <tuca...@gmail.com> wrote:
> > > Henrique, pra que WCF?
> > > Se você vai usar MVC, você pode responder em xml ou json sem problemas > > > e vc tem os principais verbos http tambem disponiveis.
> > > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > > operação de escrita ou leitura deve ter uma transação, então fica > > > fácil decidir onde colocar.
> > > Att., > > > Tuca
> > > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote:
> > > > Vms lá!
> > > > estou desenvolvendo um projeto para funcionar como SaaS, é um > projeto > > > > pessoal e por esse motivo posso decidir o que fazer nele sem > problemas de > > > > custo (até parece) e de prazo.
> > > > O que imaginei é o seguinte:
> > > > ASP.NET MVC (testei nos últimos dias e realmente é interessante)
> > > > WCF RESTFul
> > > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > > SQLServer 2008.
> > > > Em que pé está?
> > > > Bem, o modelo está bem adiantado com o domínio quase todo > implementado > > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > > > repositórios (apenas 1 real implementado pra testar o NH com o > FluenteNH)).
> > > > Somente para testar conceito implementei um webform pra falar com o > domínio > > > > e o repositório real (não tem WCF no caminho) pra testar o conceito e > testar > > > > a Transação do NH através do IHTTPModule. Está tudo funcionando... > mas aí > > > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON > (dentro de > > > > uma conexão HTTPS) > > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com > a > > > > camada de aplicação... > > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma > fachada > > > > chamando os métodos de aplicação e esse sim seria responsável por > processar > > > > o pedido e encaminhar a requisição a quem for de direito.
> > > > Primeira dúvida:
> > > > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > > > transação na camada de aplicação somente nos métodos onde houvesse > add, > > > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui > imaginar > > > > uma solução pra automatizar a criação deste contexto teria que > repetir esta > > > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu > tenho de > > > > forma automática no Init).
> > > > Segunda dúvida:
> > > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > > Tinha pensado em cria métodos utilitários de transformação de obj > pra json > > > > e usá-los na camada de aplicação. e este iria responder pra quem > solicita-se > > > > o JSON. Isso não me agrada, pois estaria fazendo a minha aplicação > ter uma > > > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar a > > > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF eu > teria que > > > > reescrever código ou mesmo duplicar.
> > > > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha > o > > > > conhecimento do modelo pra fazer a transformação e eu não quero isso. > Então > > > > pensei em um TO mas na minha visão estaria duplicando o modelo e > tirando > > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > > E por último o que acha da arquitetura de uma maneira geral.
> > > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a > parada > > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > > Com Hardware estou adquirido um servidor na DELL e vou fazer > colocation > > > > com LINK de 20MBs.
> > > > Esta arquitetura é escalável? é uma boa abordagem?
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
Nesse ponto rails é mais avançado que nosso velho .NET. Infelizmente escolher o tipo da resposta só é possível em .NET com o uso de querystring (que não é tão ruim) e o parse pro tipo escolhido deve ser feito na interface em questão que nesse caso é o WCF.
Esse processo de parse/serialização deve ficar da classe que implementa o contrato de operacao do servico.
Esse vídeo do MIX09 exemplifica e detalha mais o que eu disse acima.
Att., Tuca
On Feb 3, 1:54 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote:
> Por que quando o usuário chama /Users/Details/1, decidir se isso vai ser > respondido em HTML ou em JSON não é responsabilidade da camada de negócio, e > sim da de user interface.
> No Rails, por exemplo, existe um mecanismo padrão para escolha de > formatters. Geralmente, "/Users/Details/1" responde HTML e > "/Users/Details/1.json" responde JSON, por decisão do Controller, em uma > sintaxe como:
> > Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil igual.
> > Juan,
> > nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por > > meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC responde > > em qquer formato e WCF possui JSonSerializer também pra responder > > direto em Json.
> > Att., > > Tuca
> > On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote: > > > Opa vlw TUCAZ!
> > > Pensei em WCF pq se no futuro quiser ter uma implementação diferente > > > (mas que fosse HTTP) para um cliente específico, não teria um projeto > > > diferente e sim uma interface (UI) diferente pra cada projeto.
> > > Tb me lembro de ter passado o olho neste post do Ayende, não lembro > > > o pq desta afirmação, vc tem esse post aí( estou procurando se achar > > > posto aqui)
> > > On 3 fev, 17:09, tucaz <tuca...@gmail.com> wrote:
> > > > Henrique, pra que WCF?
> > > > Se você vai usar MVC, você pode responder em xml ou json sem problemas > > > > e vc tem os principais verbos http tambem disponiveis.
> > > > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > > > operação de escrita ou leitura deve ter uma transação, então fica > > > > fácil decidir onde colocar.
> > > > Att., > > > > Tuca
> > > > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote:
> > > > > Vms lá!
> > > > > estou desenvolvendo um projeto para funcionar como SaaS, é um > > projeto > > > > > pessoal e por esse motivo posso decidir o que fazer nele sem > > problemas de > > > > > custo (até parece) e de prazo.
> > > > > O que imaginei é o seguinte:
> > > > > ASP.NET MVC (testei nos últimos dias e realmente é interessante)
> > > > > WCF RESTFul
> > > > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > > > SQLServer 2008.
> > > > > Em que pé está?
> > > > > Bem, o modelo está bem adiantado com o domínio quase todo > > implementado > > > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > > > > repositórios (apenas 1 real implementado pra testar o NH com o > > FluenteNH)).
> > > > > Somente para testar conceito implementei um webform pra falar com o > > domínio > > > > > e o repositório real (não tem WCF no caminho) pra testar o conceito e > > testar > > > > > a Transação do NH através do IHTTPModule. Está tudo funcionando... > > mas aí > > > > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > > > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON > > (dentro de > > > > > uma conexão HTTPS) > > > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com > > a > > > > > camada de aplicação... > > > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma > > fachada > > > > > chamando os métodos de aplicação e esse sim seria responsável por > > processar > > > > > o pedido e encaminhar a requisição a quem for de direito.
> > > > > Primeira dúvida:
> > > > > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > > > > transação na camada de aplicação somente nos métodos onde houvesse > > add, > > > > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui > > imaginar > > > > > uma solução pra automatizar a criação deste contexto teria que > > repetir esta > > > > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu > > tenho de > > > > > forma automática no Init).
> > > > > Segunda dúvida:
> > > > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > > > Tinha pensado em cria métodos utilitários de transformação de obj > > pra json > > > > > e usá-los na camada de aplicação. e este iria responder pra quem > > solicita-se > > > > > o JSON. Isso não me agrada, pois estaria fazendo a minha aplicação > > ter uma > > > > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar a > > > > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF eu > > teria que > > > > > reescrever código ou mesmo duplicar.
> > > > > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha > > o > > > > > conhecimento do modelo pra fazer a transformação e eu não quero isso. > > Então > > > > > pensei em um TO mas na minha visão estaria duplicando o modelo e > > tirando > > > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > > > E por último o que acha da arquitetura de uma maneira geral.
> > > > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a > > parada > > > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > > > Com Hardware estou adquirido um servidor na DELL e vou fazer > > colocation > > > > > com LINK de 20MBs.
> > > > > Esta arquitetura é escalável? é uma boa abordagem?
> > -- > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > hospedado no Google Groups. > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > Para sair do grupo envie uma mensagem para > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > > Para mais opções visite o grupo em > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
Tuca, não é difícil escrever uma API para extender os controllers para que eles façam exatamente o que o Rails faz. O C# tem todas as qualidades para possibilitar isso.
Não é porque não é padrão do ASP.NET MVC que não possamos usar. Temos que achar um meio termo entre o excesso e a falta de NIH nas decisões arquiteturais.
> Nesse ponto rails é mais avançado que nosso velho .NET. Infelizmente > escolher o tipo da resposta só é possível em .NET com o uso de > querystring (que não é tão ruim) e o parse pro tipo escolhido deve ser > feito na interface em questão que nesse caso é o WCF.
> Esse processo de parse/serialização deve ficar da classe que > implementa o contrato de operacao do servico.
> Esse vídeo do MIX09 exemplifica e detalha mais o que eu disse acima.
> Att., > Tuca
> On Feb 3, 1:54 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote: > > Por que quando o usuário chama /Users/Details/1, decidir se isso vai ser > > respondido em HTML ou em JSON não é responsabilidade da camada de > negócio, e > > sim da de user interface.
> > No Rails, por exemplo, existe um mecanismo padrão para escolha de > > formatters. Geralmente, "/Users/Details/1" responde HTML e > > "/Users/Details/1.json" responde JSON, por decisão do Controller, em uma > > sintaxe como:
> > > Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil igual.
> > > Juan,
> > > nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por > > > meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC responde > > > em qquer formato e WCF possui JSonSerializer também pra responder > > > direto em Json.
> > > Att., > > > Tuca
> > > On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote: > > > > Opa vlw TUCAZ!
> > > > Pensei em WCF pq se no futuro quiser ter uma implementação > diferente > > > > (mas que fosse HTTP) para um cliente específico, não teria um projeto > > > > diferente e sim uma interface (UI) diferente pra cada projeto.
> > > > Tb me lembro de ter passado o olho neste post do Ayende, não lembro > > > > o pq desta afirmação, vc tem esse post aí( estou procurando se achar > > > > posto aqui)
> > > > > Se você vai usar MVC, você pode responder em xml ou json sem > problemas > > > > > e vc tem os principais verbos http tambem disponiveis.
> > > > > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > > > > operação de escrita ou leitura deve ter uma transação, então fica > > > > > fácil decidir onde colocar.
> > > > > Att., > > > > > Tuca
> > > > > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote:
> > > > > > Vms lá!
> > > > > > estou desenvolvendo um projeto para funcionar como SaaS, é um > > > projeto > > > > > > pessoal e por esse motivo posso decidir o que fazer nele sem > > > problemas de > > > > > > custo (até parece) e de prazo.
> > > > > > O que imaginei é o seguinte:
> > > > > > ASP.NET MVC (testei nos últimos dias e realmente é > interessante)
> > > > > > WCF RESTFul
> > > > > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > > > > SQLServer 2008.
> > > > > > Em que pé está?
> > > > > > Bem, o modelo está bem adiantado com o domínio quase todo > > > implementado > > > > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces > dos > > > > > > repositórios (apenas 1 real implementado pra testar o NH com o > > > FluenteNH)).
> > > > > > Somente para testar conceito implementei um webform pra falar > com o > > > domínio > > > > > > e o repositório real (não tem WCF no caminho) pra testar o > conceito e > > > testar > > > > > > a Transação do NH através do IHTTPModule. Está tudo > funcionando... > > > mas aí > > > > > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > > > > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e > JSON > > > (dentro de > > > > > > uma conexão HTTPS) > > > > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará > com > > > a > > > > > > camada de aplicação... > > > > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como > uma > > > fachada > > > > > > chamando os métodos de aplicação e esse sim seria responsável por > > > processar > > > > > > o pedido e encaminhar a requisição a quem for de direito.
> > > > > > Primeira dúvida:
> > > > > > Já que terei o WCF onde devo chamar a transação do NH? Não > usarei o > > > > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é > abrir a > > > > > > transação na camada de aplicação somente nos métodos onde > houvesse > > > add, > > > > > > merge e remove. Essa é uma boa decisão? E se for boa, não > consegui > > > imaginar > > > > > > uma solução pra automatizar a criação deste contexto teria que > > > repetir esta > > > > > > chamada em cada método e isso não me agrada(o que no IHTTPModule > eu > > > tenho de > > > > > > forma automática no Init).
> > > > > > Segunda dúvida:
> > > > > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > > > > Tinha pensado em cria métodos utilitários de transformação de > obj > > > pra json > > > > > > e usá-los na camada de aplicação. e este iria responder pra quem > > > solicita-se > > > > > > o JSON. Isso não me agrada, pois estaria fazendo a minha > aplicação > > > ter uma > > > > > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar > a > > > > > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF > eu > > > teria que > > > > > > reescrever código ou mesmo duplicar.
> > > > > > Aí pensei na em colocar no WCF mas isso implicaria em que ele > tenha > > > o > > > > > > conhecimento do modelo pra fazer a transformação e eu não quero > isso. > > > Então > > > > > > pensei em um TO mas na minha visão estaria duplicando o modelo e > > > tirando > > > > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > > > > E por último o que acha da arquitetura de uma maneira geral.
> > > > > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a > > > parada > > > > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > > > > Com Hardware estou adquirido um servidor na DELL e vou fazer > > > colocation > > > > > > com LINK de 20MBs.
> > > > > > Esta arquitetura é escalável? é uma boa abordagem?
> > > -- > > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > > hospedado no Google Groups. > > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > > Para sair do grupo envie uma mensagem para > > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > <dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%252Bunsub scribe@googlegroups.com>
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
> Tuca, não é difícil escrever uma API para extender os controllers para que > eles façam exatamente o que o Rails faz. O C# tem todas as qualidades para > possibilitar isso.
> Não é porque não é padrão do ASP.NET MVC que não possamos usar. Temos que > achar um meio termo entre o excesso e a falta de NIH nas decisões > arquiteturais.
> > Nesse ponto rails é mais avançado que nosso velho .NET. Infelizmente > > escolher o tipo da resposta só é possível em .NET com o uso de > > querystring (que não é tão ruim) e o parse pro tipo escolhido deve ser > > feito na interface em questão que nesse caso é o WCF.
> > Esse processo de parse/serialização deve ficar da classe que > > implementa o contrato de operacao do servico.
> > Esse vídeo do MIX09 exemplifica e detalha mais o que eu disse acima.
> > Att., > > Tuca
> > On Feb 3, 1:54 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote: > > > Por que quando o usuário chama /Users/Details/1, decidir se isso vai ser > > > respondido em HTML ou em JSON não é responsabilidade da camada de > > negócio, e > > > sim da de user interface.
> > > No Rails, por exemplo, existe um mecanismo padrão para escolha de > > > formatters. Geralmente, "/Users/Details/1" responde HTML e > > > "/Users/Details/1.json" responde JSON, por decisão do Controller, em uma > > > sintaxe como:
> > > > Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil igual.
> > > > Juan,
> > > > nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por > > > > meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC responde > > > > em qquer formato e WCF possui JSonSerializer também pra responder > > > > direto em Json.
> > > > Att., > > > > Tuca
> > > > On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote: > > > > > Opa vlw TUCAZ!
> > > > > Pensei em WCF pq se no futuro quiser ter uma implementação > > diferente > > > > > (mas que fosse HTTP) para um cliente específico, não teria um projeto > > > > > diferente e sim uma interface (UI) diferente pra cada projeto.
> > > > > Tb me lembro de ter passado o olho neste post do Ayende, não lembro > > > > > o pq desta afirmação, vc tem esse post aí( estou procurando se achar > > > > > posto aqui)
> > > > > > Se você vai usar MVC, você pode responder em xml ou json sem > > problemas > > > > > > e vc tem os principais verbos http tambem disponiveis.
> > > > > > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > > > > > operação de escrita ou leitura deve ter uma transação, então fica > > > > > > fácil decidir onde colocar.
> > > > > > Att., > > > > > > Tuca
> > > > > > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote:
> > > > > > > Vms lá!
> > > > > > > estou desenvolvendo um projeto para funcionar como SaaS, é um > > > > projeto > > > > > > > pessoal e por esse motivo posso decidir o que fazer nele sem > > > > problemas de > > > > > > > custo (até parece) e de prazo.
> > > > > > > O que imaginei é o seguinte:
> > > > > > > ASP.NET MVC (testei nos últimos dias e realmente é > > interessante)
> > > > > > > WCF RESTFul
> > > > > > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > > > > > SQLServer 2008.
> > > > > > > Em que pé está?
> > > > > > > Bem, o modelo está bem adiantado com o domínio quase todo > > > > implementado > > > > > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces > > dos > > > > > > > repositórios (apenas 1 real implementado pra testar o NH com o > > > > FluenteNH)).
> > > > > > > Somente para testar conceito implementei um webform pra falar > > com o > > > > domínio > > > > > > > e o repositório real (não tem WCF no caminho) pra testar o > > conceito e > > > > testar > > > > > > > a Transação do NH através do IHTTPModule. Está tudo > > funcionando... > > > > mas aí > > > > > > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > > > > > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e > > JSON > > > > (dentro de > > > > > > > uma conexão HTTPS) > > > > > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará > > com > > > > a > > > > > > > camada de aplicação... > > > > > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como > > uma > > > > fachada > > > > > > > chamando os métodos de aplicação e esse sim seria responsável por > > > > processar > > > > > > > o pedido e encaminhar a requisição a quem for de direito.
> > > > > > > Primeira dúvida:
> > > > > > > Já que terei o WCF onde devo chamar a transação do NH? Não > > usarei o > > > > > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é > > abrir a > > > > > > > transação na camada de aplicação somente nos métodos onde > > houvesse > > > > add, > > > > > > > merge e remove. Essa é uma boa decisão? E se for boa, não > > consegui > > > > imaginar > > > > > > > uma solução pra automatizar a criação deste contexto teria que > > > > repetir esta > > > > > > > chamada em cada método e isso não me agrada(o que no IHTTPModule > > eu > > > > tenho de > > > > > > > forma automática no Init).
> > > > > > > Segunda dúvida:
> > > > > > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > > > > > Tinha pensado em cria métodos utilitários de transformação de > > obj > > > > pra json > > > > > > > e usá-los na camada de aplicação. e este iria responder pra quem > > > > solicita-se > > > > > > > o JSON. Isso não me agrada, pois estaria fazendo a minha > > aplicação > > > > ter uma > > > > > > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar > > a > > > > > > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF > > eu > > > > teria que > > > > > > > reescrever código ou mesmo duplicar.
> > > > > > > Aí pensei na em colocar no WCF mas isso implicaria em que ele > > tenha > > > > o > > > > > > > conhecimento do modelo pra fazer a transformação e eu não quero > > isso. > > > > Então > > > > > > > pensei em um TO mas na minha visão estaria duplicando o modelo e > > > > tirando > > > > > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > > > > > E por último o que acha da arquitetura de uma maneira geral.
> > > > > > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a > > > > parada > > > > > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > > > > > Com Hardware estou adquirido um servidor na DELL e vou fazer > > > > colocation > > > > > > > com LINK de 20MBs.
> > > > > > > Esta arquitetura é escalável? é uma boa abordagem?
> > > > -- > > > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > > > hospedado no Google Groups. > > > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > > > Para sair do grupo envie uma mensagem para > > > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > > <dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%252Bunsub scribe@googlegroups.com>
> > -- > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > hospedado no Google Groups. > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > Para sair do grupo envie uma mensagem para > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > > Para mais opções visite o grupo em > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
Concordo com o Tucaz, aliás Henrique eu tenho uma estrutura parecida com a sua, tanto que o MVC combater que teve era juustamente quando eu tive essa mesma dúvida que você, mas enfim.
Não entendo para que os serviços, por algum motivo os metodos disponibilizados poderão ser acessados como API por outras aplicações? Pois só faz sentido para mim em situações como essas.
Se for esse o caso, então o MVC irá responder como serviço também? O controller irá chamar um serviço?
Com relação a infra aqui não tenho problemas e minha maquina sobra performance, dá para para colocar muita gente simultaneamente.
> Claro, Juan. Agora já nem sei mais do que estamos falando. Eu estava > falando de WCF e vc de MVC. ehehe
> O problema de aceitar /Usuario/1.xml e /Usuario/1.json eh que temos > que mapear os handlers no IIS pra que o .NET responda.
> On Feb 3, 2:04 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote: > > Tuca, não é difícil escrever uma API para extender os controllers para > que > > eles façam exatamente o que o Rails faz. O C# tem todas as qualidades > para > > possibilitar isso.
> > Não é porque não é padrão do ASP.NET <http://asp.net/> MVC que não > possamos usar. Temos que > > achar um meio termo entre o excesso e a falta de NIH nas decisões > > arquiteturais.
> > > Nesse ponto rails é mais avançado que nosso velho .NET. Infelizmente > > > escolher o tipo da resposta só é possível em .NET com o uso de > > > querystring (que não é tão ruim) e o parse pro tipo escolhido deve ser > > > feito na interface em questão que nesse caso é o WCF.
> > > Esse processo de parse/serialização deve ficar da classe que > > > implementa o contrato de operacao do servico.
> > > Esse vídeo do MIX09 exemplifica e detalha mais o que eu disse acima.
> > > Att., > > > Tuca
> > > On Feb 3, 1:54 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote: > > > > Por que quando o usuário chama /Users/Details/1, decidir se isso vai > ser > > > > respondido em HTML ou em JSON não é responsabilidade da camada de > > > negócio, e > > > > sim da de user interface.
> > > > No Rails, por exemplo, existe um mecanismo padrão para escolha de > > > > formatters. Geralmente, "/Users/Details/1" responde HTML e > > > > "/Users/Details/1.json" responde JSON, por decisão do Controller, em > uma > > > > sintaxe como:
> > > > > Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil > igual.
> > > > > Juan,
> > > > > nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por > > > > > meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC > responde > > > > > em qquer formato e WCF possui JSonSerializer também pra responder > > > > > direto em Json.
> > > > > Att., > > > > > Tuca
> > > > > On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote: > > > > > > Opa vlw TUCAZ!
> > > > > > Pensei em WCF pq se no futuro quiser ter uma implementação > > > diferente > > > > > > (mas que fosse HTTP) para um cliente específico, não teria um > projeto > > > > > > diferente e sim uma interface (UI) diferente pra cada projeto.
> > > > > > Tb me lembro de ter passado o olho neste post do Ayende, não > lembro > > > > > > o pq desta afirmação, vc tem esse post aí( estou procurando se > achar > > > > > > posto aqui)
> > > > > > > Se você vai usar MVC, você pode responder em xml ou json sem > > > problemas > > > > > > > e vc tem os principais verbos http tambem disponiveis.
> > > > > > > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > > > > > > operação de escrita ou leitura deve ter uma transação, então > fica > > > > > > > fácil decidir onde colocar.
> > > > > > > Att., > > > > > > > Tuca
> > > > > > > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> > wrote:
> > > > > > > > Vms lá!
> > > > > > > > estou desenvolvendo um projeto para funcionar como SaaS, é > um > > > > > projeto > > > > > > > > pessoal e por esse motivo posso decidir o que fazer nele sem > > > > > problemas de > > > > > > > > custo (até parece) e de prazo.
> > > > > > > > O que imaginei é o seguinte:
> > > > > > > > ASP.NET <http://asp.net/> MVC (testei nos últimos dias e > realmente é > > > interessante)
> > > > > > > > WCF RESTFul
> > > > > > > > DDD (não sei se do EVANS mas algo muito próximo dos > conceitos)
> > > > > > > > SQLServer 2008.
> > > > > > > > Em que pé está?
> > > > > > > > Bem, o modelo está bem adiantado com o domínio quase todo > > > > > implementado > > > > > > > > (Aplicações, Domínios, Services e MOCK respeitando as > interfaces > > > dos > > > > > > > > repositórios (apenas 1 real implementado pra testar o NH com > o > > > > > FluenteNH)).
> > > > > > > > Somente para testar conceito implementei um webform pra > falar > > > com o > > > > > domínio > > > > > > > > e o repositório real (não tem WCF no caminho) pra testar o > > > conceito e > > > > > testar > > > > > > > > a Transação do NH através do IHTTPModule. Está tudo > > > funcionando... > > > > > mas aí > > > > > > > > começam as minhas dúvidas em que caminho seguir, então vms > lá.
> > > > > > > > 1 - O meu ASP.NET <http://asp.net/> MVC terá apenas HTML, > JQUERY (ou EXTJS) e > > > JSON > > > > > (dentro de > > > > > > > > uma conexão HTTPS) > > > > > > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse > falará > > > com > > > > > a > > > > > > > > camada de aplicação... > > > > > > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas > como > > > uma > > > > > fachada > > > > > > > > chamando os métodos de aplicação e esse sim seria responsável > por > > > > > processar > > > > > > > > o pedido e encaminhar a requisição a quem for de direito.
> > > > > > > > Primeira dúvida:
> > > > > > > > Já que terei o WCF onde devo chamar a transação do NH? Não > > > usarei o > > > > > > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é > > > abrir a > > > > > > > > transação na camada de aplicação somente nos métodos onde > > > houvesse > > > > > add, > > > > > > > > merge e remove. Essa é uma boa decisão? E se for boa, não > > > consegui > > > > > imaginar > > > > > > > > uma solução pra automatizar a criação deste contexto teria > que > > > > > repetir esta > > > > > > > > chamada em cada método e isso não me agrada(o que no > IHTTPModule > > > eu > > > > > tenho de > > > > > > > > forma automática no Init).
> > > > > > > > Segunda dúvida:
> > > > > > > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > > > > > > Tinha pensado em cria métodos utilitários de transformação > de > > > obj > > > > > pra json > > > > > > > > e usá-los na camada de aplicação. e este iria responder pra > quem > > > > > solicita-se > > > > > > > > o JSON. Isso não me agrada, pois estaria fazendo a minha > > > aplicação > > > > > ter uma > > > > > > > > responsabilidade tecnológica (JSON) e se depois eu quisesse > mudar > > > a > > > > > > > > abordagem ou acoplar uma outra interface (UI) que não fosse > WCF > > > eu > > > > > teria que > > > > > > > > reescrever código ou mesmo duplicar.
> > > > > > > > Aí pensei na em colocar no WCF mas isso implicaria em que > ele > > > tenha > > > > > o > > > > > > > > conhecimento do modelo pra fazer a transformação e eu não > quero > > > isso. > > > > > Então > > > > > > > > pensei em um TO mas na minha visão estaria duplicando o > modelo e > > > > > tirando > > > > > > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > > > > > > E por último o que acha da arquitetura de uma maneira geral.
> > > > > > > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e > se a > > > > > parada > > > > > > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > > > > > > Com Hardware estou adquirido um servidor na DELL e vou > fazer > > > > > colocation > > > > > > > > com LINK de 20MBs.
> > > > > > > > Esta arquitetura é escalável? é uma boa abordagem?
> > > > > -- > > > > > Você recebeu esta mensagem porque faz parte do grupo .Net > Architects > > > > > hospedado no Google Groups. > > > > > Para postar envie uma mensagem para > dotnetarchitects@googlegroups.com > > > > > Para sair do grupo envie uma mensagem para > > > > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > <dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%252Bunsub scribe@googlegroups.com>
Mesmo que a aplicação atenda outras aplicações e exponha uma API não vejo problema. O único motivo seria futuras necessidades e questão de organização. Eu ia falar escalabilidade, mas se sua aplicação estiver OK você escala com balanceamento de carga e ta tudo lindo.
Acho que WCF só justificaria no caso de expor uma API rest pra uma aplicação WebForms ou de outra plataforma tecnologica ou caso da sua aplicação precisar conversar em outros protocolos diferente de http/ rest.
Do contrario, vc pode expor seu model em REST com MVC sem o uso de WCF sem problemas. Pelo menos não consigo enxer um motivo para não faze- lo. Talvez o pessoal q tem mais experiência com MVC possa dizer alguma coisa.
On Feb 3, 2:30 pm, Sidney Lima Filho <sidney.fi...@vivina.com.br> wrote:
> Concordo com o Tucaz, aliás Henrique eu tenho uma estrutura parecida com a > sua, tanto que o MVC combater que teve era juustamente quando eu tive essa > mesma dúvida que você, mas enfim.
> Não entendo para que os serviços, por algum motivo os metodos > disponibilizados poderão ser acessados como API por outras aplicações? Pois > só faz sentido para mim em situações como essas.
> Se for esse o caso, então o MVC irá responder como serviço também? O > controller irá chamar um serviço?
> Com relação a infra aqui não tenho problemas e minha maquina sobra > performance, dá para para colocar muita gente simultaneamente.
> > Claro, Juan. Agora já nem sei mais do que estamos falando. Eu estava > > falando de WCF e vc de MVC. ehehe
> > O problema de aceitar /Usuario/1.xml e /Usuario/1.json eh que temos > > que mapear os handlers no IIS pra que o .NET responda.
> > On Feb 3, 2:04 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote: > > > Tuca, não é difícil escrever uma API para extender os controllers para > > que > > > eles façam exatamente o que o Rails faz. O C# tem todas as qualidades > > para > > > possibilitar isso.
> > > Não é porque não é padrão do ASP.NET <http://asp.net/> MVC que não > > possamos usar. Temos que > > > achar um meio termo entre o excesso e a falta de NIH nas decisões > > > arquiteturais.
> > > > Nesse ponto rails é mais avançado que nosso velho .NET. Infelizmente > > > > escolher o tipo da resposta só é possível em .NET com o uso de > > > > querystring (que não é tão ruim) e o parse pro tipo escolhido deve ser > > > > feito na interface em questão que nesse caso é o WCF.
> > > > Esse processo de parse/serialização deve ficar da classe que > > > > implementa o contrato de operacao do servico.
> > > > Esse vídeo do MIX09 exemplifica e detalha mais o que eu disse acima.
> > > > Att., > > > > Tuca
> > > > On Feb 3, 1:54 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote: > > > > > Por que quando o usuário chama /Users/Details/1, decidir se isso vai > > ser > > > > > respondido em HTML ou em JSON não é responsabilidade da camada de > > > > negócio, e > > > > > sim da de user interface.
> > > > > No Rails, por exemplo, existe um mecanismo padrão para escolha de > > > > > formatters. Geralmente, "/Users/Details/1" responde HTML e > > > > > "/Users/Details/1.json" responde JSON, por decisão do Controller, em > > uma > > > > > sintaxe como:
> > > > > > Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil > > igual.
> > > > > > Juan,
> > > > > > nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por > > > > > > meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC > > responde > > > > > > em qquer formato e WCF possui JSonSerializer também pra responder > > > > > > direto em Json.
> > > > > > Att., > > > > > > Tuca
> > > > > > On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote: > > > > > > > Opa vlw TUCAZ!
> > > > > > > Pensei em WCF pq se no futuro quiser ter uma implementação > > > > diferente > > > > > > > (mas que fosse HTTP) para um cliente específico, não teria um > > projeto > > > > > > > diferente e sim uma interface (UI) diferente pra cada projeto.
> > > > > > > Tb me lembro de ter passado o olho neste post do Ayende, não > > lembro > > > > > > > o pq desta afirmação, vc tem esse post aí( estou procurando se > > achar > > > > > > > posto aqui)
> > > > > > > > Se você vai usar MVC, você pode responder em xml ou json sem > > > > problemas > > > > > > > > e vc tem os principais verbos http tambem disponiveis.
> > > > > > > > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > > > > > > > operação de escrita ou leitura deve ter uma transação, então > > fica > > > > > > > > fácil decidir onde colocar.
> > > > > > > > Att., > > > > > > > > Tuca
> > > > > > > > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> > > wrote:
> > > > > > > > > Vms lá!
> > > > > > > > > estou desenvolvendo um projeto para funcionar como SaaS, é > > um > > > > > > projeto > > > > > > > > > pessoal e por esse motivo posso decidir o que fazer nele sem > > > > > > problemas de > > > > > > > > > custo (até parece) e de prazo.
> > > > > > > > > O que imaginei é o seguinte:
> > > > > > > > > ASP.NET <http://asp.net/> MVC (testei nos últimos dias e > > realmente é > > > > interessante)
> > > > > > > > > WCF RESTFul
> > > > > > > > > DDD (não sei se do EVANS mas algo muito próximo dos > > conceitos)
> > > > > > > > > SQLServer 2008.
> > > > > > > > > Em que pé está?
> > > > > > > > > Bem, o modelo está bem adiantado com o domínio quase todo > > > > > > implementado > > > > > > > > > (Aplicações, Domínios, Services e MOCK respeitando as > > interfaces > > > > dos > > > > > > > > > repositórios (apenas 1 real implementado pra testar o NH com > > o > > > > > > FluenteNH)).
> > > > > > > > > Somente para testar conceito implementei um webform pra > > falar > > > > com o > > > > > > domínio > > > > > > > > > e o repositório real (não tem WCF no caminho) pra testar o > > > > conceito e > > > > > > testar > > > > > > > > > a Transação do NH através do IHTTPModule. Está tudo > > > > funcionando... > > > > > > mas aí > > > > > > > > > começam as minhas dúvidas em que caminho seguir, então vms > > lá.
> > > > > > > > > 1 - O meu ASP.NET <http://asp.net/> MVC terá apenas HTML, > > JQUERY (ou EXTJS) e > > > > JSON > > > > > > (dentro de > > > > > > > > > uma conexão HTTPS) > > > > > > > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse > > falará > > > > com > > > > > > a > > > > > > > > > camada de aplicação... > > > > > > > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas > > como > > > > uma > > > > > > fachada > > > > > > > > > chamando os métodos de aplicação e esse sim seria responsável > > por > > > > > > processar > > > > > > > > > o pedido e encaminhar a requisição a quem for de direito.
> > > > > > > > > Primeira dúvida:
> > > > > > > > > Já que terei o WCF onde devo chamar a transação do NH? Não > > > > usarei o > > > > > > > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é > > > > abrir a > > > > > > > > > transação na camada de aplicação somente nos métodos onde > > > > houvesse > > > > > > add, > > > > > > > > > merge e remove. Essa é uma boa decisão? E se for boa, não > > > > consegui > > > > > > imaginar > > > > > > > > > uma solução pra automatizar a criação deste contexto teria > > que > > > > > > repetir esta > > > > > > > > > chamada em cada método e isso não me agrada(o que no > > IHTTPModule > > > > eu > > > > > > tenho de > > > > > > > > > forma automática no Init).
> > > > > > > > > Segunda dúvida:
> > > > > > > > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > > > > > > > Tinha pensado em cria métodos utilitários de transformação > > de > > > > obj > > > > > > pra json > > > > > > > > > e usá-los na camada de aplicação. e este iria responder pra > > quem > > > > > > solicita-se > > > > > > > > > o JSON. Isso não me agrada, pois estaria fazendo a minha > > > > aplicação > > > > > > ter uma > > > > > > > > > responsabilidade tecnológica (JSON) e se depois eu quisesse > > mudar > > > > a > > > > > > > > > abordagem ou acoplar uma outra interface (UI) que não fosse > > WCF > > > > eu > > > > > > teria que > > > > > > > > > reescrever código ou mesmo duplicar.
> > > > > > > > > Aí pensei na em colocar no WCF mas isso implicaria em que > > ele > > > > tenha > > > > > > o > > > > > > > > > conhecimento do modelo pra fazer a transformação e eu não > > quero > > > > isso. > > > > > > Então > > > > > > > > > pensei em um TO mas na minha visão estaria duplicando o > > modelo e > > > > > > tirando > > > > > > > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > > > > > > > E por último o que acha da arquitetura de uma maneira geral.
> > > > > > > > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e > > se a > > > > > > parada > > > > > > > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> Nesse ponto rails é mais avançado que nosso velho .NET. Infelizmente > escolher o tipo da resposta só é possível em .NET com o uso de > querystring (que não é tão ruim) e o parse pro tipo escolhido deve ser > feito na interface em qruestão que nesse caso é o WCF.
> Esse processo de parse/serialização deve ficar da classe que > implementa o contrato de operacao do servico.
> Esse vídeo do MIX09 exemplifica e detalha mais o que eu disse acima.
> Att., > Tuca
> On Feb 3, 1:54 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote: > > Por que quando o usuário chama /Users/Details/1, decidir se isso vai ser > > respondido em HTML ou em JSON não é responsabilidade da camada de > negócio, e > > sim da de user interface.
> > No Rails, por exemplo, existe um mecanismo padrão para escolha de > > formatters. Geralmente, "/Users/Details/1" responde HTML e > > "/Users/Details/1.json" responde JSON, por decisão do Controller, em uma > > sintaxe como:
> > > Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil igual.
> > > Juan,
> > > nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por > > > meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC responde > > > em qquer formato e WCF possui JSonSerializer também pra responder > > > direto em Json.
> > > Att., > > > Tuca
> > > On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote: > > > > Opa vlw TUCAZ!
> > > > Pensei em WCF pq se no futuro quiser ter uma implementação > diferente > > > > (mas que fosse HTTP) para um cliente específico, não teria um projeto > > > > diferente e sim uma interface (UI) diferente pra cada projeto.
> > > > Tb me lembro de ter passado o olho neste post do Ayende, não lembro > > > > o pq desta afirmação, vc tem esse post aí( estou procurando se achar > > > > posto aqui)
> > > > > Se você vai usar MVC, você pode responder em xml ou json sem > problemas > > > > > e vc tem os principais verbos http tambem disponiveis.
> > > > > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > > > > operação de escrita ou leitura deve ter uma transação, então fica > > > > > fácil decidir onde colocar.
> > > > > Att., > > > > > Tuca
> > > > > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote:
> > > > > > Vms lá!
> > > > > > estou desenvolvendo um projeto para funcionar como SaaS, é um > > > projeto > > > > > > pessoal e por esse motivo posso decidir o que fazer nele sem > > > problemas de > > > > > > custo (até parece) e de prazo.
> > > > > > O que imaginei é o seguinte:
> > > > > > ASP.NET MVC (testei nos últimos dias e realmente é > interessante)
> > > > > > WCF RESTFul
> > > > > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > > > > SQLServer 2008.
> > > > > > Em que pé está?
> > > > > > Bem, o modelo está bem adiantado com o domínio quase todo > > > implementado > > > > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces > dos > > > > > > repositórios (apenas 1 real implementado pra testar o NH com o > > > FluenteNH)).
> > > > > > Somente para testar conceito implementei um webform pra falar > com o > > > domínio > > > > > > e o repositório real (não tem WCF no caminho) pra testar o > conceito e > > > testar > > > > > > a Transação do NH através do IHTTPModule. Está tudo > funcionando... > > > mas aí > > > > > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > > > > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e > JSON > > > (dentro de > > > > > > uma conexão HTTPS) > > > > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará > com > > > a > > > > > > camada de aplicação... > > > > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como > uma > > > fachada > > > > > > chamando os métodos de aplicação e esse sim seria responsável por > > > processar > > > > > > o pedido e encaminhar a requisição a quem for de direito.
> > > > > > Primeira dúvida:
> > > > > > Já que terei o WCF onde devo chamar a transação do NH? Não > usarei o > > > > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é > abrir a > > > > > > transação na camada de aplicação somente nos métodos onde > houvesse > > > add, > > > > > > merge e remove. Essa é uma boa decisão? E se for boa, não > consegui > > > imaginar > > > > > > uma solução pra automatizar a criação deste contexto teria que > > > repetir esta > > > > > > chamada em cada método e isso não me agrada(o que no IHTTPModule > eu > > > tenho de > > > > > > forma automática no Init).
> > > > > > Segunda dúvida:
> > > > > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > > > > Tinha pensado em cria métodos utilitários de transformação de > obj > > > pra json > > > > > > e usá-los na camada de aplicação. e este iria responder pra quem > > > solicita-se > > > > > > o JSON. Isso não me agrada, pois estaria fazendo a minha > aplicação > > > ter uma > > > > > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar > a > > > > > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF > eu > > > teria que > > > > > > reescrever código ou mesmo duplicar.
> > > > > > Aí pensei na em colocar no WCF mas isso implicaria em que ele > tenha > > > o > > > > > > conhecimento do modelo pra fazer a transformação e eu não quero > isso. > > > Então > > > > > > pensei em um TO mas na minha visão estaria duplicando o modelo e > > > tirando > > > > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > > > > E por último o que acha da arquitetura de uma maneira geral.
> > > > > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a > > > parada > > > > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > > > > Com Hardware estou adquirido um servidor na DELL e vou fazer > > > colocation > > > > > > com LINK de 20MBs.
> > > > > > Esta arquitetura é escalável? é uma boa abordagem?
> > > -- > > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > > hospedado no Google Groups. > > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > > Para sair do grupo envie uma mensagem para > > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > <dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%252Bunsub scribe@googlegroups.com>
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
Eu havia pensando em WCF. pq eu teria duas modalidades de venda:
1 - que eu venderia o SaaS completo (Core + Interface(UI))
2 - Eu venderia somente o Core e o cliente implementaria a interface no que ele bem entendesse....
Não sei se essa é uma boa estratégia de venda, mas eu teria essa facilidade com um "custo" de desenvolvimento relativamente baixo....
Uma outra possibilidade é vender aplicativos Desktops, Mobile, que iriam sincronizar on-line....
ou seja, eu teria um único sistema com diversas interfaces....
Ou até pra importação de dados de clientes... eu teria um serviço de cadastro de usuários (por exemplo) e bastaria que o cliente respeitasse o contrato....
On 3 fev, 22:39, Thiago Alves <thiago1...@gmail.com> wrote:
> > Nesse ponto rails é mais avançado que nosso velho .NET. Infelizmente > > escolher o tipo da resposta só é possível em .NET com o uso de > > querystring (que não é tão ruim) e o parse pro tipo escolhido deve ser > > feito na interface em qruestão que nesse caso é o WCF.
> > Esse processo de parse/serialização deve ficar da classe que > > implementa o contrato de operacao do servico.
> > Esse vídeo do MIX09 exemplifica e detalha mais o que eu disse acima.
> > Att., > > Tuca
> > On Feb 3, 1:54 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote: > > > Por que quando o usuário chama /Users/Details/1, decidir se isso vai ser > > > respondido em HTML ou em JSON não é responsabilidade da camada de > > negócio, e > > > sim da de user interface.
> > > No Rails, por exemplo, existe um mecanismo padrão para escolha de > > > formatters. Geralmente, "/Users/Details/1" responde HTML e > > > "/Users/Details/1.json" responde JSON, por decisão do Controller, em uma > > > sintaxe como:
> > > > Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil igual.
> > > > Juan,
> > > > nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por > > > > meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC responde > > > > em qquer formato e WCF possui JSonSerializer também pra responder > > > > direto em Json.
> > > > Att., > > > > Tuca
> > > > On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote: > > > > > Opa vlw TUCAZ!
> > > > > Pensei em WCF pq se no futuro quiser ter uma implementação > > diferente > > > > > (mas que fosse HTTP) para um cliente específico, não teria um projeto > > > > > diferente e sim uma interface (UI) diferente pra cada projeto.
> > > > > Tb me lembro de ter passado o olho neste post do Ayende, não lembro > > > > > o pq desta afirmação, vc tem esse post aí( estou procurando se achar > > > > > posto aqui)
> > > > > > Se você vai usar MVC, você pode responder em xml ou json sem > > problemas > > > > > > e vc tem os principais verbos http tambem disponiveis.
> > > > > > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > > > > > operação de escrita ou leitura deve ter uma transação, então fica > > > > > > fácil decidir onde colocar.
> > > > > > Att., > > > > > > Tuca
> > > > > > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote:
> > > > > > > Vms lá!
> > > > > > > estou desenvolvendo um projeto para funcionar como SaaS, é um > > > > projeto > > > > > > > pessoal e por esse motivo posso decidir o que fazer nele sem > > > > problemas de > > > > > > > custo (até parece) e de prazo.
> > > > > > > O que imaginei é o seguinte:
> > > > > > > ASP.NET MVC (testei nos últimos dias e realmente é > > interessante)
> > > > > > > WCF RESTFul
> > > > > > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > > > > > SQLServer 2008.
> > > > > > > Em que pé está?
> > > > > > > Bem, o modelo está bem adiantado com o domínio quase todo > > > > implementado > > > > > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces > > dos > > > > > > > repositórios (apenas 1 real implementado pra testar o NH com o > > > > FluenteNH)).
> > > > > > > Somente para testar conceito implementei um webform pra falar > > com o > > > > domínio > > > > > > > e o repositório real (não tem WCF no caminho) pra testar o > > conceito e > > > > testar > > > > > > > a Transação do NH através do IHTTPModule. Está tudo > > funcionando... > > > > mas aí > > > > > > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > > > > > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e > > JSON > > > > (dentro de > > > > > > > uma conexão HTTPS) > > > > > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará > > com > > > > a > > > > > > > camada de aplicação... > > > > > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como > > uma > > > > fachada > > > > > > > chamando os métodos de aplicação e esse sim seria responsável por > > > > processar > > > > > > > o pedido e encaminhar a requisição a quem for de direito.
> > > > > > > Primeira dúvida:
> > > > > > > Já que terei o WCF onde devo chamar a transação do NH? Não > > usarei o > > > > > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é > > abrir a > > > > > > > transação na camada de aplicação somente nos métodos onde > > houvesse > > > > add, > > > > > > > merge e remove. Essa é uma boa decisão? E se for boa, não > > consegui > > > > imaginar > > > > > > > uma solução pra automatizar a criação deste contexto teria que > > > > repetir esta > > > > > > > chamada em cada método e isso não me agrada(o que no IHTTPModule > > eu > > > > tenho de > > > > > > > forma automática no Init).
> > > > > > > Segunda dúvida:
> > > > > > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > > > > > Tinha pensado em cria métodos utilitários de transformação de > > obj > > > > pra json > > > > > > > e usá-los na camada de aplicação. e este iria responder pra quem > > > > solicita-se > > > > > > > o JSON. Isso não me agrada, pois estaria fazendo a minha > > aplicação > > > > ter uma > > > > > > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar > > a > > > > > > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF > > eu > > > > teria que > > > > > > > reescrever código ou mesmo duplicar.
> > > > > > > Aí pensei na em colocar no WCF mas isso implicaria em que ele > > tenha > > > > o > > > > > > > conhecimento do modelo pra fazer a transformação e eu não quero > > isso. > > > > Então > > > > > > > pensei em um TO mas na minha visão estaria duplicando o modelo e > > > > tirando > > > > > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > > > > > E por último o que acha da arquitetura de uma maneira geral.
> > > > > > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a > > > > parada > > > > > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > > > > > Com Hardware estou adquirido um servidor na DELL e vou fazer > > > > colocation > > > > > > > com LINK de 20MBs.
> > > > > > > Esta arquitetura é escalável? é uma boa abordagem?
> > > > -- > > > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > > > hospedado no Google Groups. > > > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > > > Para sair do grupo envie uma mensagem para > > > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > > <dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%252Bunsub scribe@googlegroups.com>
> > -- > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > hospedado no Google Groups. > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > Para sair do grupo envie uma mensagem para > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > > Para mais opções visite o grupo em > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
> Eu havia pensando em WCF. pq eu teria duas modalidades de venda:
> 1 - que eu venderia o SaaS completo (Core + Interface(UI))
> 2 - Eu venderia somente o Core e o cliente implementaria a interface > no que ele bem entendesse....
> Não sei se essa é uma boa estratégia de venda, mas eu teria essa > facilidade com um "custo" de desenvolvimento relativamente baixo....
> Uma outra possibilidade é vender aplicativos Desktops, Mobile, que > iriam sincronizar on-line....
> ou seja, eu teria um único sistema com diversas interfaces....
> Ou até pra importação de dados de clientes... eu teria um serviço de > cadastro de usuários (por exemplo) e bastaria que o cliente > respeitasse o contrato....
> On 3 fev, 22:39, Thiago Alves <thiago1...@gmail.com> wrote: > > No ASP.NET MVC 2 basta o método do controller retornar um JsonResult, em > vez > > em um ActionResult
> > Mas tenho que admitir que o jeito do rails é mais legal :)
> > > Nesse ponto rails é mais avançado que nosso velho .NET. Infelizmente > > > escolher o tipo da resposta só é possível em .NET com o uso de > > > querystring (que não é tão ruim) e o parse pro tipo escolhido deve ser > > > feito na interface em qruestão que nesse caso é o WCF.
> > > Esse processo de parse/serialização deve ficar da classe que > > > implementa o contrato de operacao do servico.
> > > Esse vídeo do MIX09 exemplifica e detalha mais o que eu disse acima.
> > > Att., > > > Tuca
> > > On Feb 3, 1:54 pm, "Juan Pedro A. Lopes" <zerova...@gmail.com> wrote: > > > > Por que quando o usuário chama /Users/Details/1, decidir se isso vai > ser > > > > respondido em HTML ou em JSON não é responsabilidade da camada de > > > negócio, e > > > > sim da de user interface.
> > > > No Rails, por exemplo, existe um mecanismo padrão para escolha de > > > > formatters. Geralmente, "/Users/Details/1" responde HTML e > > > > "/Users/Details/1.json" responde JSON, por decisão do Controller, em > uma > > > > sintaxe como:
> > > > > Quanto ao HTTP, YAGNI. Qdo vc precisar, vc cria. Vai ser fácil > igual.
> > > > > Juan,
> > > > > nao entendi seu ponto. Se o Henrique quer chamar os "servicos" por > > > > > meio de JS pra que usar Controller E WCF? Ou um ou outro. MVC > responde > > > > > em qquer formato e WCF possui JSonSerializer também pra responder > > > > > direto em Json.
> > > > > Att., > > > > > Tuca
> > > > > On Feb 3, 1:18 pm, Henrique Jacob <analista....@gmail.com> wrote: > > > > > > Opa vlw TUCAZ!
> > > > > > Pensei em WCF pq se no futuro quiser ter uma implementação > > > diferente > > > > > > (mas que fosse HTTP) para um cliente específico, não teria um > projeto > > > > > > diferente e sim uma interface (UI) diferente pra cada projeto.
> > > > > > Tb me lembro de ter passado o olho neste post do Ayende, não > lembro > > > > > > o pq desta afirmação, vc tem esse post aí( estou procurando se > achar > > > > > > posto aqui)
> > > > > > > Se você vai usar MVC, você pode responder em xml ou json sem > > > problemas > > > > > > > e vc tem os principais verbos http tambem disponiveis.
> > > > > > > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > > > > > > operação de escrita ou leitura deve ter uma transação, então > fica > > > > > > > fácil decidir onde colocar.
> > > > > > > Att., > > > > > > > Tuca
> > > > > > > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> > wrote:
> > > > > > > > Vms lá!
> > > > > > > > estou desenvolvendo um projeto para funcionar como SaaS, é > um > > > > > projeto > > > > > > > > pessoal e por esse motivo posso decidir o que fazer nele sem > > > > > problemas de > > > > > > > > custo (até parece) e de prazo.
> > > > > > > > O que imaginei é o seguinte:
> > > > > > > > ASP.NET MVC (testei nos últimos dias e realmente é > > > interessante)
> > > > > > > > WCF RESTFul
> > > > > > > > DDD (não sei se do EVANS mas algo muito próximo dos > conceitos)
> > > > > > > > SQLServer 2008.
> > > > > > > > Em que pé está?
> > > > > > > > Bem, o modelo está bem adiantado com o domínio quase todo > > > > > implementado > > > > > > > > (Aplicações, Domínios, Services e MOCK respeitando as > interfaces > > > dos > > > > > > > > repositórios (apenas 1 real implementado pra testar o NH com > o > > > > > FluenteNH)).
> > > > > > > > Somente para testar conceito implementei um webform pra > falar > > > com o > > > > > domínio > > > > > > > > e o repositório real (não tem WCF no caminho) pra testar o > > > conceito e > > > > > testar > > > > > > > > a Transação do NH através do IHTTPModule. Está tudo > > > funcionando... > > > > > mas aí > > > > > > > > começam as minhas dúvidas em que caminho seguir, então vms > lá.
> > > > > > > > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e > > > JSON > > > > > (dentro de > > > > > > > > uma conexão HTTPS) > > > > > > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse > falará > > > com > > > > > a > > > > > > > > camada de aplicação... > > > > > > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas > como > > > uma > > > > > fachada > > > > > > > > chamando os métodos de aplicação e esse sim seria responsável > por > > > > > processar > > > > > > > > o pedido e encaminhar a requisição a quem for de direito.
> > > > > > > > Primeira dúvida:
> > > > > > > > Já que terei o WCF onde devo chamar a transação do NH? Não > > > usarei o > > > > > > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é > > > abrir a > > > > > > > > transação na camada de aplicação somente nos métodos onde > > > houvesse > > > > > add, > > > > > > > > merge e remove. Essa é uma boa decisão? E se for boa, não > > > consegui > > > > > imaginar > > > > > > > > uma solução pra automatizar a criação deste contexto teria > que > > > > > repetir esta > > > > > > > > chamada em cada método e isso não me agrada(o que no > IHTTPModule > > > eu > > > > > tenho de > > > > > > > > forma automática no Init).
> > > > > > > > Segunda dúvida:
> > > > > > > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > > > > > > Tinha pensado em cria métodos utilitários de transformação > de > > > obj > > > > > pra json > > > > > > > > e usá-los na camada de aplicação. e este iria responder pra > quem > > > > > solicita-se > > > > > > > > o JSON. Isso não me agrada, pois estaria fazendo a minha > > > aplicação > > > > > ter uma > > > > > > > > responsabilidade tecnológica (JSON) e se depois eu quisesse > mudar > > > a > > > > > > > > abordagem ou acoplar uma outra interface (UI) que não fosse > WCF > > > eu > > > > > teria que > > > > > > > > reescrever código ou mesmo duplicar.
> > > > > > > > Aí pensei na em colocar no WCF mas isso implicaria em que > ele > > > tenha > > > > > o > > > > > > > > conhecimento do modelo pra fazer a transformação e eu não > quero > > > isso. > > > > > Então > > > > > > > > pensei em um TO mas na minha visão estaria duplicando o > modelo e > > > > > tirando > > > > > > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > > > > > > E por último o que acha da arquitetura de uma maneira geral.
> > > > > > > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e > se a > > > > > parada > > > > > > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > > > > > > Com Hardware estou adquirido um servidor na DELL e vou > fazer > > > > > colocation > > > > > > > > com LINK de 20MBs.
> > > > > > > > Esta arquitetura é escalável? é uma boa abordagem?
> > > > > -- > > > > > Você recebeu esta mensagem porque faz parte do grupo .Net > Architects > > > > > hospedado no Google Groups. > > > > > Para postar envie uma mensagem para > dotnetarchitects@googlegroups.com > > > > > Para sair do grupo envie uma mensagem para > > > > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com><dotnetarchitects%2Bunsubscrib > e@googlegroups.com> > > > <dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%252Bunsub scribe@googlegroups.com><dotnetarchitects%252Bunsub > scribe@googlegroups.com>
> > > -- > > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > > hospedado no Google Groups. > > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > > Para sair do grupo envie uma mensagem para > > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com><dotnetarchitects%2Bunsubscrib > e@googlegroups.com> > > > Para mais opções visite o grupo em > > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
> -- > Você recebeu esta mensagem porque faz parte do grupo
Acredito que o WCF deva retornar um tipo de dado que toda e qualquer interface possa ler. Pode ser um XML, DTOs, etc. Daí cabera a quem fez a requisição fazer o que precisa com os dados para apresentá-los. O MVC vai converter para um JSON e se fosse um Desktop poderia receber um xml ... e por aí vai !!
Estou iniciando com o WCF e vejo ele com bons olhos porque me permite ter um sistema distribuído e ao mesmo tempo centralizar todo meu negócio ... deixando a parte da interface separada e burra (como deve ser a UI).
Quanto as sessões, sempre é possível resolver muitas coisas via herança, mas isso te tira parte do controle sobre o que está acontecendo ... eu acho que iniciar uma transação/sessão na mão apesar de ser chato, garante que vai acontecer o que vc deseja e somente quando vc desejar.
O NH é para o WCF ... a UI não precisa saber se vc usa NH, EF ou qualquer outra coisa. Quando chamar o método do serviço, ele fará o que é necessário ... um CriarPedido(Pedido pedido) do serviço vai criar o pedido com seus itens e fazer toda parte de estoque, contas a pagar e receber, comissionamento, etc ... tua UI chama este método e só recebe o sucesso ou não ... não precisa saber como o pedido é adicionado nem o que ele vai fazer !!!
[]'s
Ricardo José Alves da Rocha Porto Alegre - RS
Em 3 de fevereiro de 2010 16:50, Henrique Jacob <analista....@gmail.com>escreveu:
> estou desenvolvendo um projeto para funcionar como SaaS, é um projeto > pessoal e por esse motivo posso decidir o que fazer nele sem problemas de > custo (até parece) e de prazo.
> O que imaginei é o seguinte:
> ASP.NET MVC (testei nos últimos dias e realmente é interessante)
> WCF RESTFul
> DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> SQLServer 2008.
> Em que pé está?
> Bem, o modelo está bem adiantado com o domínio quase todo implementado > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > repositórios (apenas 1 real implementado pra testar o NH com o FluenteNH)).
> Somente para testar conceito implementei um webform pra falar com o > domínio e o repositório real (não tem WCF no caminho) pra testar o conceito > e testar a Transação do NH através do IHTTPModule. Está tudo funcionando... > mas aí começam as minhas dúvidas em que caminho seguir, então vms lá.
> 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON (dentro > de uma conexão HTTPS) > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > camada de aplicação... > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma fachada > chamando os métodos de aplicação e esse sim seria responsável por processar > o pedido e encaminhar a requisição a quem for de direito.
> Primeira dúvida:
> Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > transação na camada de aplicação somente nos métodos onde houvesse add, > merge e remove. Essa é uma boa decisão? E se for boa, não consegui imaginar > uma solução pra automatizar a criação deste contexto teria que repetir esta > chamada em cada método e isso não me agrada(o que no IHTTPModule eu tenho de > forma automática no Init).
> Segunda dúvida:
> Onde devo criar o Json? na camada de aplicação ou WCF? > Tinha pensado em cria métodos utilitários de transformação de obj pra > json e usá-los na camada de aplicação. e este iria responder pra quem > solicita-se o JSON. Isso não me agrada, pois estaria fazendo a minha > aplicação ter uma responsabilidade tecnológica (JSON) e se depois eu > quisesse mudar a abordagem ou acoplar uma outra interface (UI) que não fosse > WCF eu teria que reescrever código ou mesmo duplicar.
> Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > conhecimento do modelo pra fazer a transformação e eu não quero isso. Então > pensei em um TO mas na minha visão estaria duplicando o modelo e tirando > apenas dele o comportamento. Alguém tem alguma sugestão?
> E por último o que acha da arquitetura de uma maneira geral.
> A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a parada > bombar mesmo a idéia é começar a vender pra empresas tb.
> Com Hardware estou adquirido um servidor na DELL e vou fazer colocation > com LINK de 20MBs.
> Esta arquitetura é escalável? é uma boa abordagem?
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
> Acredito que o WCF deva retornar um tipo de dado que toda e qualquer > interface possa ler. Pode ser um XML, DTOs, etc. Daí cabera a quem fez a > requisição fazer o que precisa com os dados para apresentá-los. O MVC vai > converter para um JSON e se fosse um Desktop poderia receber um xml ... e > por aí vai !!
> Estou iniciando com o WCF e vejo ele com bons olhos porque me permite ter um > sistema distribuído e ao mesmo tempo centralizar todo meu negócio ... > deixando a parte da interface separada e burra (como deve ser a UI).
> Quanto as sessões, sempre é possível resolver muitas coisas via herança, mas > isso te tira parte do controle sobre o que está acontecendo ... eu acho que > iniciar uma transação/sessão na mão apesar de ser chato, garante que vai > acontecer o que vc deseja e somente quando vc desejar.
> O NH é para o WCF ... a UI não precisa saber se vc usa NH, EF ou qualquer > outra coisa. Quando chamar o método do serviço, ele fará o que é necessário > ... um CriarPedido(Pedido pedido) do serviço vai criar o pedido com seus > itens e fazer toda parte de estoque, contas a pagar e receber, > comissionamento, etc ... tua UI chama este método e só recebe o sucesso ou > não ... não precisa saber como o pedido é adicionado nem o que ele vai fazer > !!!
> []'s
> Ricardo José Alves da Rocha > Porto Alegre - RS
> Em 3 de fevereiro de 2010 16:50, Henrique Jacob > <analista....@gmail.com>escreveu:
> > Vms lá!
> > estou desenvolvendo um projeto para funcionar como SaaS, é um projeto > > pessoal e por esse motivo posso decidir o que fazer nele sem problemas de > > custo (até parece) e de prazo.
> > O que imaginei é o seguinte:
> > ASP.NET MVC (testei nos últimos dias e realmente é interessante)
> > WCF RESTFul
> > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > SQLServer 2008.
> > Em que pé está?
> > Bem, o modelo está bem adiantado com o domínio quase todo implementado > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > repositórios (apenas 1 real implementado pra testar o NH com o FluenteNH)).
> > Somente para testar conceito implementei um webform pra falar com o > > domínio e o repositório real (não tem WCF no caminho) pra testar o conceito > > e testar a Transação do NH através do IHTTPModule. Está tudo funcionando... > > mas aí começam as minhas dúvidas em que caminho seguir, então vms lá.
> > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON (dentro > > de uma conexão HTTPS) > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > > camada de aplicação... > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma fachada > > chamando os métodos de aplicação e esse sim seria responsável por processar > > o pedido e encaminhar a requisição a quem for de direito.
> > Primeira dúvida:
> > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > transação na camada de aplicação somente nos métodos onde houvesse add, > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui imaginar > > uma solução pra automatizar a criação deste contexto teria que repetir esta > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu tenho de > > forma automática no Init).
> > Segunda dúvida:
> > Onde devo criar o Json? na camada de aplicação ou WCF? > > Tinha pensado em cria métodos utilitários de transformação de obj pra > > json e usá-los na camada de aplicação. e este iria responder pra quem > > solicita-se o JSON. Isso não me agrada, pois estaria fazendo a minha > > aplicação ter uma responsabilidade tecnológica (JSON) e se depois eu > > quisesse mudar a abordagem ou acoplar uma outra interface (UI) que não fosse > > WCF eu teria que reescrever código ou mesmo duplicar.
> > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > > conhecimento do modelo pra fazer a transformação e eu não quero isso. Então > > pensei em um TO mas na minha visão estaria duplicando o modelo e tirando > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > E por último o que acha da arquitetura de uma maneira geral.
> > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a parada > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > Com Hardware estou adquirido um servidor na DELL e vou fazer colocation > > com LINK de 20MBs.
> > Esta arquitetura é escalável? é uma boa abordagem?
> > -- > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > hospedado no Google Groups. > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > Para sair do grupo envie uma mensagem para > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > > Para mais opções visite o grupo em > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
> Lembrem-se que a primeira regra para sistema distribuidos é: não faça > um sistema distribuido.
> On Feb 4, 5:32 am, Ricardo Rocha <ricardorocha....@gmail.com> wrote: > > Henrique,
> > Acredito que o WCF deva retornar um tipo de dado que toda e qualquer > > interface possa ler. Pode ser um XML, DTOs, etc. Daí cabera a quem fez a > > requisição fazer o que precisa com os dados para apresentá-los. O MVC vai > > converter para um JSON e se fosse um Desktop poderia receber um xml ... e > > por aí vai !!
> > Estou iniciando com o WCF e vejo ele com bons olhos porque me permite ter > um > > sistema distribuído e ao mesmo tempo centralizar todo meu negócio ... > > deixando a parte da interface separada e burra (como deve ser a UI).
> > Quanto as sessões, sempre é possível resolver muitas coisas via herança, > mas > > isso te tira parte do controle sobre o que está acontecendo ... eu acho > que > > iniciar uma transação/sessão na mão apesar de ser chato, garante que vai > > acontecer o que vc deseja e somente quando vc desejar.
> > O NH é para o WCF ... a UI não precisa saber se vc usa NH, EF ou qualquer > > outra coisa. Quando chamar o método do serviço, ele fará o que é > necessário > > ... um CriarPedido(Pedido pedido) do serviço vai criar o pedido com seus > > itens e fazer toda parte de estoque, contas a pagar e receber, > > comissionamento, etc ... tua UI chama este método e só recebe o sucesso > ou > > não ... não precisa saber como o pedido é adicionado nem o que ele vai > fazer > > !!!
> > []'s
> > Ricardo José Alves da Rocha > > Porto Alegre - RS
> > Em 3 de fevereiro de 2010 16:50, Henrique Jacob > > <analista....@gmail.com>escreveu:
> > > Vms lá!
> > > estou desenvolvendo um projeto para funcionar como SaaS, é um > projeto > > > pessoal e por esse motivo posso decidir o que fazer nele sem problemas > de > > > custo (até parece) e de prazo.
> > > O que imaginei é o seguinte:
> > > ASP.NET MVC (testei nos últimos dias e realmente é interessante)
> > > WCF RESTFul
> > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > SQLServer 2008.
> > > Em que pé está?
> > > Bem, o modelo está bem adiantado com o domínio quase todo > implementado > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > > repositórios (apenas 1 real implementado pra testar o NH com o > FluenteNH)).
> > > Somente para testar conceito implementei um webform pra falar com o > > > domínio e o repositório real (não tem WCF no caminho) pra testar o > conceito > > > e testar a Transação do NH através do IHTTPModule. Está tudo > funcionando... > > > mas aí começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > 1 - O meu ASP.NET MVC terá apenas HTML, JQUERY (ou EXTJS) e JSON > (dentro > > > de uma conexão HTTPS) > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > > > camada de aplicação... > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma > fachada > > > chamando os métodos de aplicação e esse sim seria responsável por > processar > > > o pedido e encaminhar a requisição a quem for de direito.
> > > Primeira dúvida:
> > > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > > transação na camada de aplicação somente nos métodos onde houvesse > add, > > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui > imaginar > > > uma solução pra automatizar a criação deste contexto teria que repetir > esta > > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu > tenho de > > > forma automática no Init).
> > > Segunda dúvida:
> > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > Tinha pensado em cria métodos utilitários de transformação de obj pra > > > json e usá-los na camada de aplicação. e este iria responder pra quem > > > solicita-se o JSON. Isso não me agrada, pois estaria fazendo a minha > > > aplicação ter uma responsabilidade tecnológica (JSON) e se depois eu > > > quisesse mudar a abordagem ou acoplar uma outra interface (UI) que não > fosse > > > WCF eu teria que reescrever código ou mesmo duplicar.
> > > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > > > conhecimento do modelo pra fazer a transformação e eu não quero isso. > Então > > > pensei em um TO mas na minha visão estaria duplicando o modelo e > tirando > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > E por último o que acha da arquitetura de uma maneira geral.
> > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a > parada > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > Com Hardware estou adquirido um servidor na DELL e vou fazer > colocation > > > com LINK de 20MBs.
> > > Esta arquitetura é escalável? é uma boa abordagem?
> > > -- > > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > > hospedado no Google Groups. > > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > > Para sair do grupo envie uma mensagem para > > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > <dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%252Bunsub scribe@googlegroups.com>
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
> Lembrem-se que a primeira regra para sistema distribuidos é: não faça > um sistema distribuido.
> On Feb 4, 5:32 am, Ricardo Rocha <ricardorocha....@gmail.com> wrote: > > Henrique,
> > Acredito que o WCF deva retornar um tipo de dado que toda e qualquer > > interface possa ler. Pode ser um XML, DTOs, etc. Daí cabera a quem fez a > > requisição fazer o que precisa com os dados para apresentá-los. O MVC vai > > converter para um JSON e se fosse um Desktop poderia receber um xml ... e > > por aí vai !!
> > Estou iniciando com o WCF e vejo ele com bons olhos porque me permite ter > um > > sistema distribuído e ao mesmo tempo centralizar todo meu negócio ... > > deixando a parte da interface separada e burra (como deve ser a UI).
> > Quanto as sessões, sempre é possível resolver muitas coisas via herança, > mas > > isso te tira parte do controle sobre o que está acontecendo ... eu acho > que > > iniciar uma transação/sessão na mão apesar de ser chato, garante que vai > > acontecer o que vc deseja e somente quando vc desejar.
> > O NH é para o WCF ... a UI não precisa saber se vc usa NH, EF ou qualquer > > outra coisa. Quando chamar o método do serviço, ele fará o que é > necessário > > ... um CriarPedido(Pedido pedido) do serviço vai criar o pedido com seus > > itens e fazer toda parte de estoque, contas a pagar e receber, > > comissionamento, etc ... tua UI chama este método e só recebe o sucesso > ou > > não ... não precisa saber como o pedido é adicionado nem o que ele vai > fazer > > !!!
> > []'s
> > Ricardo José Alves da Rocha > > Porto Alegre - RS
> > Em 3 de fevereiro de 2010 16:50, Henrique Jacob > > <analista....@gmail.com>escreveu:
> > > Vms lá!
> > > estou desenvolvendo um projeto para funcionar como SaaS, é um > projeto > > > pessoal e por esse motivo posso decidir o que fazer nele sem problemas > de > > > custo (até parece) e de prazo.
> > > O que imaginei é o seguinte:
> > > ASP.NET <http://asp.net/> MVC (testei nos últimos dias e realmente > é interessante)
> > > WCF RESTFul
> > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > SQLServer 2008.
> > > Em que pé está?
> > > Bem, o modelo está bem adiantado com o domínio quase todo > implementado > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > > repositórios (apenas 1 real implementado pra testar o NH com o > FluenteNH)).
> > > Somente para testar conceito implementei um webform pra falar com o > > > domínio e o repositório real (não tem WCF no caminho) pra testar o > conceito > > > e testar a Transação do NH através do IHTTPModule. Está tudo > funcionando... > > > mas aí começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > 1 - O meu ASP.NET <http://asp.net/> MVC terá apenas HTML, JQUERY (ou > EXTJS) e JSON (dentro > > > de uma conexão HTTPS) > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > > > camada de aplicação... > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma > fachada > > > chamando os métodos de aplicação e esse sim seria responsável por > processar > > > o pedido e encaminhar a requisição a quem for de direito.
> > > Primeira dúvida:
> > > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > > transação na camada de aplicação somente nos métodos onde houvesse > add, > > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui > imaginar > > > uma solução pra automatizar a criação deste contexto teria que repetir > esta > > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu > tenho de > > > forma automática no Init).
> > > Segunda dúvida:
> > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > Tinha pensado em cria métodos utilitários de transformação de obj pra > > > json e usá-los na camada de aplicação. e este iria responder pra quem > > > solicita-se o JSON. Isso não me agrada, pois estaria fazendo a minha > > > aplicação ter uma responsabilidade tecnológica (JSON) e se depois eu > > > quisesse mudar a abordagem ou acoplar uma outra interface (UI) que não > fosse > > > WCF eu teria que reescrever código ou mesmo duplicar.
> > > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > > > conhecimento do modelo pra fazer a transformação e eu não quero isso. > Então > > > pensei em um TO mas na minha visão estaria duplicando o modelo e > tirando > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > E por último o que acha da arquitetura de uma maneira geral.
> > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a > parada > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > Com Hardware estou adquirido um servidor na DELL e vou fazer > colocation > > > com LINK de 20MBs.
> > > Esta arquitetura é escalável? é uma boa abordagem?
> > > -- > > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > > hospedado no Google Groups. > > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > > Para sair do grupo envie uma mensagem para > > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > <dotnetarchitects%2Bunsubscribe@googlegroups.com<dotnetarchitects%252Bunsub scribe@googlegroups.com>
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
Nesse caso, como o Herique disse que vai disponibilizar serviços na modalidade SaaS, como você implementaria segurança? Ex. Se ele quiser que somente clientes autorizados consumam os serviços através de usuário e senha.
Abraço
André
Em 3 de fevereiro de 2010 17:09, tucaz <tuca...@gmail.com> escreveu:
> Se você vai usar MVC, você pode responder em xml ou json sem problemas > e vc tem os principais verbos http tambem disponiveis.
> Quanto a transação do NHibernate, de acordo com o Ayende, TODA > operação de escrita ou leitura deve ter uma transação, então fica > fácil decidir onde colocar.
> Att., > Tuca
> On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote: > > Vms lá!
> > estou desenvolvendo um projeto para funcionar como SaaS, é um projeto > > pessoal e por esse motivo posso decidir o que fazer nele sem problemas de > > custo (até parece) e de prazo.
> > O que imaginei é o seguinte:
> > ASP.NET <http://asp.net/> MVC (testei nos últimos dias e realmente é > interessante)
> > WCF RESTFul
> > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > SQLServer 2008.
> > Em que pé está?
> > Bem, o modelo está bem adiantado com o domínio quase todo implementado > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > repositórios (apenas 1 real implementado pra testar o NH com o > FluenteNH)).
> > Somente para testar conceito implementei um webform pra falar com o > domínio > > e o repositório real (não tem WCF no caminho) pra testar o conceito e > testar > > a Transação do NH através do IHTTPModule. Está tudo funcionando... mas aí > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > 1 - O meu ASP.NET <http://asp.net/> MVC terá apenas HTML, JQUERY (ou > EXTJS) e JSON (dentro de > > uma conexão HTTPS) > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > > camada de aplicação... > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma > fachada > > chamando os métodos de aplicação e esse sim seria responsável por > processar > > o pedido e encaminhar a requisição a quem for de direito.
> > Primeira dúvida:
> > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > transação na camada de aplicação somente nos métodos onde houvesse add, > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui > imaginar > > uma solução pra automatizar a criação deste contexto teria que repetir > esta > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu tenho > de > > forma automática no Init).
> > Segunda dúvida:
> > Onde devo criar o Json? na camada de aplicação ou WCF? > > Tinha pensado em cria métodos utilitários de transformação de obj pra > json > > e usá-los na camada de aplicação. e este iria responder pra quem > solicita-se > > o JSON. Isso não me agrada, pois estaria fazendo a minha aplicação ter > uma > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar a > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF eu teria > que > > reescrever código ou mesmo duplicar.
> > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > > conhecimento do modelo pra fazer a transformação e eu não quero isso. > Então > > pensei em um TO mas na minha visão estaria duplicando o modelo e tirando > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > E por último o que acha da arquitetura de uma maneira geral.
> > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a parada > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > Com Hardware estou adquirido um servidor na DELL e vou fazer colocation > > com LINK de 20MBs.
> > Esta arquitetura é escalável? é uma boa abordagem?
> -- > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > hospedado no Google Groups. > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > Para sair do grupo envie uma mensagem para > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > Para mais opções visite o grupo em > http://groups.google.com/group/dotnetarchitects?hl=pt-br
> Nesse caso, como o Herique disse que vai disponibilizar serviços na > modalidade SaaS, como você implementaria segurança? Ex. Se ele quiser que > somente clientes autorizados consumam os serviços através de usuário e > senha.
> Abraço
> André
> Em 3 de fevereiro de 2010 17:09, tucaz <tuca...@gmail.com> escreveu:
> > Henrique, pra que WCF?
> > Se você vai usar MVC, você pode responder em xml ou json sem problemas > > e vc tem os principais verbos http tambem disponiveis.
> > Quanto a transação do NHibernate, de acordo com o Ayende, TODA > > operação de escrita ou leitura deve ter uma transação, então fica > > fácil decidir onde colocar.
> > Att., > > Tuca
> > On Feb 3, 12:50 pm, Henrique Jacob <analista....@gmail.com> wrote: > > > Vms lá!
> > > estou desenvolvendo um projeto para funcionar como SaaS, é um projeto > > > pessoal e por esse motivo posso decidir o que fazer nele sem problemas de > > > custo (até parece) e de prazo.
> > > O que imaginei é o seguinte:
> > > ASP.NET <http://asp.net/> MVC (testei nos últimos dias e realmente é > > interessante)
> > > WCF RESTFul
> > > DDD (não sei se do EVANS mas algo muito próximo dos conceitos)
> > > SQLServer 2008.
> > > Em que pé está?
> > > Bem, o modelo está bem adiantado com o domínio quase todo implementado > > > (Aplicações, Domínios, Services e MOCK respeitando as interfaces dos > > > repositórios (apenas 1 real implementado pra testar o NH com o > > FluenteNH)).
> > > Somente para testar conceito implementei um webform pra falar com o > > domínio > > > e o repositório real (não tem WCF no caminho) pra testar o conceito e > > testar > > > a Transação do NH através do IHTTPModule. Está tudo funcionando... mas aí > > > começam as minhas dúvidas em que caminho seguir, então vms lá.
> > > 1 - O meu ASP.NET <http://asp.net/> MVC terá apenas HTML, JQUERY (ou > > EXTJS) e JSON (dentro de > > > uma conexão HTTPS) > > > 2 - Ele irá interagir com o serviço RESTFul do WCF e esse falará com a > > > camada de aplicação... > > > 3 - O meu WCF não terá nenhuma lógica funcionaria apenas como uma > > fachada > > > chamando os métodos de aplicação e esse sim seria responsável por > > processar > > > o pedido e encaminhar a requisição a quem for de direito.
> > > Primeira dúvida:
> > > Já que terei o WCF onde devo chamar a transação do NH? Não usarei o > > > IHTTPModule (nem sei se tem no MVC) - O que tinha pensado é abrir a > > > transação na camada de aplicação somente nos métodos onde houvesse add, > > > merge e remove. Essa é uma boa decisão? E se for boa, não consegui > > imaginar > > > uma solução pra automatizar a criação deste contexto teria que repetir > > esta > > > chamada em cada método e isso não me agrada(o que no IHTTPModule eu tenho > > de > > > forma automática no Init).
> > > Segunda dúvida:
> > > Onde devo criar o Json? na camada de aplicação ou WCF? > > > Tinha pensado em cria métodos utilitários de transformação de obj pra > > json > > > e usá-los na camada de aplicação. e este iria responder pra quem > > solicita-se > > > o JSON. Isso não me agrada, pois estaria fazendo a minha aplicação ter > > uma > > > responsabilidade tecnológica (JSON) e se depois eu quisesse mudar a > > > abordagem ou acoplar uma outra interface (UI) que não fosse WCF eu teria > > que > > > reescrever código ou mesmo duplicar.
> > > Aí pensei na em colocar no WCF mas isso implicaria em que ele tenha o > > > conhecimento do modelo pra fazer a transformação e eu não quero isso. > > Então > > > pensei em um TO mas na minha visão estaria duplicando o modelo e tirando > > > apenas dele o comportamento. Alguém tem alguma sugestão?
> > > E por último o que acha da arquitetura de uma maneira geral.
> > > A Aplicação pretende ter 10000 usuários (se Deus quiser) e se a parada > > > bombar mesmo a idéia é começar a vender pra empresas tb.
> > > Com Hardware estou adquirido um servidor na DELL e vou fazer colocation > > > com LINK de 20MBs.
> > > Esta arquitetura é escalável? é uma boa abordagem?
> > -- > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects > > hospedado no Google Groups. > > Para postar envie uma mensagem para dotnetarchitects@googlegroups.com > > Para sair do grupo envie uma mensagem para > > dotnetarchitects+unsubscribe@googlegroups.com<dotnetarchitects%2Bunsubscrib e@googlegroups.com> > > Para mais opções visite o grupo em > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
