Projeto que estou implementando minhas decisões são boas?

6 visualizações
Pular para a primeira mensagem não lida

Henrique Jacob

não lida,
3 de fev. de 2010 13:50:4703/02/2010
para dotnetar...@googlegroups.com
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?

tucaz

não lida,
3 de fev. de 2010 14:09:2503/02/2010
para .Net Architects
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

Juan Pedro A. Lopes

não lida,
3 de fev. de 2010 14:16:2403/02/2010
para dotnetar...@googlegroups.com
Responder em JSON, para mim, é uma decisão de interface. O WCF deveria responder um DTO e o controller decidiria como responderia a esse request.

Quanto ao WCF, também pergunto: por que?

2010/2/3 tucaz <tuc...@gmail.com>
--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

Henrique Jacob

não lida,
3 de fev. de 2010 14:18:0803/02/2010
para .Net Architects
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)

tucaz

não lida,
3 de fev. de 2010 14:36:2203/02/2010
para .Net Architects
Henrique, seguem uns links:

http://nhprof.com/Learn/Alerts/DoNotUseImplicitTransactions
http://jasondentler.com/blog/2009/09/part-9-nhibernate-transactions/

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

Juan Pedro A. Lopes

não lida,
3 de fev. de 2010 14:54:5403/02/2010
para dotnetar...@googlegroups.com
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

2010/2/3 tucaz <tuc...@gmail.com>

tucaz

não lida,
3 de fev. de 2010 14:58:3603/02/2010
para .Net Architects
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:
>
> respond_to do |format|
>     format.html
>     format.xml  { render :xml => @user }
>     format.json  { render :json => @user }
> end
>

> 2010/2/3 tucaz <tuca...@gmail.com>

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

Juan Pedro A. Lopes

não lida,
3 de fev. de 2010 15:04:5903/02/2010
para dotnetar...@googlegroups.com
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.

2010/2/3 tucaz <tuc...@gmail.com>

tucaz

não lida,
3 de fev. de 2010 15:07:2403/02/2010
para .Net Architects
Faltou o link neh? http://videos.visitmix.com/MIX09/T64M

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 MVC que não possamos usar. Temos que
> achar um meio termo entre o excesso e a falta de NIH nas decisões
> arquiteturais.
>

> 2010/2/3 tucaz <tuca...@gmail.com>

> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>

Sidney Lima Filho

não lida,
3 de fev. de 2010 15:30:2503/02/2010
para dotnetar...@googlegroups.com
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.
 



Sidney Lima Filho  ---------------------------------------------------------------------
Vivina Softhouse
(0xx21) 7867-2321
55*10*68934
http://www.vivina.com.br
http://twitter.com/sidneyfilho


2010/2/3 tucaz <tuc...@gmail.com>

tucaz

não lida,
3 de fev. de 2010 15:37:1203/02/2010
para .Net Architects
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.
>
> Sidney Lima Filho
>  ---------------------------------------------------------------------
> Vivina Softhouse
> (0xx21) 7867-2321
> 55*10*68934http://www.vivina.com.brhttp://twitter.com/sidneyfilho
>

> 2010/2/3 tucaz <tuca...@gmail.com>
>
> > Faltou o link neh?http://videos.visitmix.com/MIX09/T64M


>
> > 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

> > > > > > > > >    ASP.NET <http://asp.net/> MVC (testei nos últimos dias e

> > > > > > > > >  1 - O meu ASP.NET <http://asp.net/> MVC terá apenas HTML,

> > > > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> > <dotnetarchitects%252Buns...@googlegroups.com<dotnetarchitects%25252Bun...@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 .Net Architects
> > > > hospedado no Google Groups.
> > > > Para
>

> ...
>
> read more »

Thiago Alves

não lida,
3 de fev. de 2010 19:39:1703/02/2010
para dotnetar...@googlegroups.com
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 :)

Abraço,
Thiago Alves

2010/2/3 tucaz <tuc...@gmail.com>
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.

Henrique Jacob

não lida,
3 de fev. de 2010 22:42:5903/02/2010
para .Net Architects
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 :)
>
> Abraço,
> Thiago Alves
>

> 2010/2/3 tucaz <tuca...@gmail.com>

> > > > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>
> > <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Bunsub scr...@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 .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib e...@googlegroups.com>

Bruno DAléssio

não lida,
3 de fev. de 2010 22:55:3603/02/2010
para dotnetar...@googlegroups.com
WCF funciona muito bem com o que você pretende.
Quanto aos conceitos e tecnologias enumerados, estou de acordo tambem.

Tenho 2 casos de arquitetura quase iguais, por isso meu "agree" tão rápido, hehe!

Boa sorte na empreitada!

Abraço,
"Um passo a frente e você não esta mais no mesmo lugar!"

Chico Sciense

Ricardo Rocha

não lida,
4 de fev. de 2010 06:32:2504/02/2010
para dotnetar...@googlegroups.com
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


tucaz

não lida,
4 de fev. de 2010 09:47:2904/02/2010
para .Net Architects
Lembrem-se que a primeira regra para sistema distribuidos é: não faça
um sistema distribuido.

> <analista....@gmail.com>escreveu:

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

Alexandre Monteiro

não lida,
4 de fev. de 2010 10:48:0204/02/2010
para dotnetar...@googlegroups.com
Pois é, evite fronteiras sempre que possível.

Régis Soares

não lida,
4 de fev. de 2010 11:52:0304/02/2010
para dotnetar...@googlegroups.com
Eu conheço essa frase aí para objetos...
 
seuTexto.Replace("sistema distribuidos", "objetos distribuidos");
seuTexto.Replace("faça um sistema distribuido", "distribua seus objetos");


 
2010/2/4 tucaz <tuc...@gmail.com>

André Silva

não lida,
8 de fev. de 2010 06:37:4708/02/2010
para dotnetar...@googlegroups.com
Tucaz,
 
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é

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br



--
André Luiz de Oliveira Silva

tucaz

não lida,
8 de fev. de 2010 06:42:5908/02/2010
para .Net Architects
André,

ele pode trabalhar no mesmo modelo do Google Maps, fornecendo uma API
KEY para os consumidores que passariam esse valor como parametro.

Att.,
Tuca

On 8 fev, 09:37, André Silva <alosi...@gmail.com> wrote:
> Tucaz,
>
> 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

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>

Responder a todos
Responder ao autor
Encaminhar
0 nova mensagem