P1 - Architectural framework for .NET based solutions

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Bruno Fiorentino

unread,

Feb 7, 2012, 1:09:22 PM2/7/12

to dotnetar...@googlegroups.com

Acho o esforço válido pelo seguinte:

#1 Apesar de tê-lo chamado de "framework", considero a implementação bem pequena, e tenta "não ficar no caminho" quando é preciso dar um "by pass". Outro ponto é que é mais uma maneira de organizar as coisas, "cóódigo mesmo" tem nos geradores, nem tanto, e não são intrusivos, o resto é literalmente organização e "glue code".

#2 Alguém começou o OpenRasta e o Backbone.js, por exemplo. É grande a chance de que foram formados a partir de pedacinhos da experiência de quem começou... depois passaram por um processo de trabalho/marketing/adoção/seleção que lhes deram maior estabilidade e visibilidade, no entanto existem outras ferramentas por aí sem tanta pretensão, ou mesmo pretensiosas mas que falharam no processo descrito, mas que podem ser úteis. Seja por completo, ou fornecendo um componente isolado, um "code snippet" ou um insight, ou mesmo -- em defesa do valor de expor código, em ambos os extremos -- um anti-pattern a ser evitado.

#3 Nesse projeto, o intuito era trabalhar ênfase em ASP .NET MVC e WCF. Ferramentas como OpenRasta e ServiceStack (*alternativas* ao WCF) são interessantes, mas nesse caso fiz um um esforço de criar uma solução onde pudesse focar em POCOs dentro de uma stack "mais popular", por assim dizer. Muita gente acha que Windsor e NHibernate já é "hardcore" demais, então para ter algum sossego com "meus POCOs" entre outros detalhes que considero importantes, levei esse aspecto social em consideração. De qualquer forma, não considero o WCF uma ferramenta ruim: é bem flexível e as configurações tem ficado cada vez mais simples (better defaults).

#4 É *muito barato* usar IoC/DI/AOP, usaria em quase todo os projetos. Na minha opinião, com C# os benefícios são muito grandes e as ferramentas são super simples. Dá pra fazer IoC de outras maneiras, mas para componentes de maior granularidade acho bastante útil: e ainda tem DI/AOP, gerenciamento de ciclo de vida entre outros xtras de cada container...

#5

Sempre que conversamos sobre um Framework arquitetural, ou sobre arquiteturas pré-definidas, com ferramentas pré-selecionadas, ainda que exista a flexibilidade (eu dei uma olhada na home do git) acha que exista uma abordagem onde isto não seja uma forma de não avaliar complexidade que pode ser desnecessária?

Eu concordo com o princípio de evitar complexidade desnecessária e venho tentando aplicá-lo, mas para discutir a aplicação do princípio é preciso de exemplos específicos ou melhor ainda concretos.

#6 Hoje eu não gosto de linguagens dinâmicas: principalmente JavaScript. Uso no bowser pq, bem, não tem jeito. De qualquer forma, dada a popularidade e a quantidade de pessoas que usam, gostam e falam muito bem, estou tentando explorar essa minha resistência estudando Python: me pareceu a mais estruturada e também com o ecossistema mais diverso. O mínimo que vou obter de retorno no investimento é uma boa linguagem de scripting na minha toolbox, para complementar as soluções que desenvolvo.

2012/2/7 Daniel Moreira Yokoyama <moreira....@gmail.com>

Daniel Moreira Yokoyama

unread,

Feb 7, 2012, 1:31:22 PM2/7/12

to dotnetar...@googlegroups.com

O exemplo concreto de abraçar complexidade desnecessária com framework arquitetural e ferramentas pré-selecionadas é justamente o fato de assumir que vc vai usar um parque de ferramentas sem necessariamente avaliar a necessidade delas.

O melhor exemplo é o container de IoC. Nem sempre pra fazer IoC você precisa do container, no entanto o seu template (não sei como chamá-lo, já que não concordou com o termo "Framework") já inclui o Windsor. E não só ele. Por exemplo, você já assumiu que suas classes geradas (algo do qual eu tenho muito medo de usar) sejam compatíveis com o WCF (interpreto isto como que já gerando classes que estejam decoradas com DataContract e DataMembers).

Eu tento não ser tão categórico nas coisas que eu afirmo, mas quando eu ouço falar de POCO's como classes geradas automaticamente seguindo algum template de metadados, eu acabo sendo levado a crer que estamos falando na verdade de um modelo anêmico. De fato, eu não consigo ver um modelo baseado em geração de código que não seja anêmico. No entanto, é muita pretenciosidade minha achar que você não saiba que POCO e Modelo Anêmico não sejam a mesma coisa. Além disso, eu estou abusando da sorte, mantendo esta conversa sem de fato abrir o código e dar uma olhada, o que me faz correr o risco de falar bobagens.

Mas, como que eu posso pré-assumir que meu software terá distribuição? E como eu posso, assumindo que haverá, assumir que a geração de código me dará uma distribuição satisfatória baseada em metadados como templates para a geração dos meus POCO's?

Isso tudo me soa muito Data-Driven. Com pouco espaço pra atuar no negócio propriamente dito já que não se pode usar metadados pra gerar comportamento (posso estar equivocado aqui, e estou assumindo este risco justamente pra facilitar o esclarecimento).

O Openrasta não foi feito com a mesma motivação. Na verdade ele é uma ferramenta específica pra criar serviços Rest. Não que eu não concorde com o que falou, mas eu acho que o que vale discutir aqui acima de tudo é a motivação. A premissa do projeto não é só pretenciosa (que não necessariamente um problema, como acabei de concordar). Mas a questão é se ela é aplicável.

E se eu não quiser ORM, por ter escolhido um outro tipo de storage, como NoSql, ou lokad?

Enfim, o que estou querendo dizer é que o "template" assume muitas coisas.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Ricardo

unread,

Feb 7, 2012, 4:19:37 PM2/7/12

to dotnetar...@googlegroups.com

Bruno, 

Estou aprendendo arquitetura para Web e acho interessante o projeto para resolver algumas dúvidas que tenho.

O exemplo que tem no git parece que é um simples cadastro de um produto, abaixo pequeno trecho 
das classes que dá para outras pessoas entenderem. 


public class Product : Entity<int> {

    [Length(50)]

    public virtual string Name { get; set; }

    [Range(1, 100)]

    public virtual int Number { get; set; }

public class ProductsController : Controller {

private readonly IProductsService productsService;

public ProductsController(IProductsService productsService) {

this.productsService = productsService;

}

public ActionResult Create(Product prod) {

var id = this.productsService.Create(prod);

return this.RedirectToAction("retrieveall");

}

  public class DefaultProductsService : IProductsService {

    [NHTransaction]

    [Authorize(SecurityNames.Operations.App_ProductsService_Create)]

    public int Create(Product prod) {

      NHContext.Session.Save(prod);

      NHContext.Session.Flush();

      return prod.Id;

Vou começar com algumas dúvidas que tenho:

1) O que chama de Service seria o mesmo que muitos chamam de Repositório. Seria apenas para acessar o banco ou colocaria alguma regra de negócio neste serviço ?

2) Aonde faria uma validação do tipo não permitir a criação de dois produtos com o mesmo número ( Number ), no Service ? Gostaria de fazer validação via consulta do Nhibernate e não usar por exemplo o um índice no banco de dados.

Ricardo

Bruno Fiorentino

unread,

Feb 7, 2012, 4:33:56 PM2/7/12

to dotnetar...@googlegroups.com

Entendo duas preocupações e considero os questionamentos válidos, mas, realmente, vc tá me devendo pelo menos uma lida lá nos txt's :)

Vamos lá:

Para usar exatamente como está, em primeiro lugar é preciso assumir que MVC, IoC/DI/AOP, ORM e as respectivas implementações se aplicam ao projeto em questão. Concordo que esses items podem não se aplicar a alguns projetos, ou então quem está elaborando está com mindset "minimalista" e pode entregar valor por outras vias, enfim: tradeoffs, escolhas, viés... faz parte.

Remover o IoC fx "derrubaria" muita coisa, é melhor buscar uma solução alternativa -- o que inclui criar algo do zero. Dá para não usar ORM -- perdendo os benefícios imediatos e ainda a verificação declarativa de autorização, baseada em Rhino.Security, por sua vez dependente de NHibernate --, mas mesmo usando ORM nada impede que se faça queries diretas ou com, sei lá um Dapper.NET (Micro ORM), ou mesmo consultas a outros tipos de banco, o que pode ser muito produtivo, um bom equilíbrio entre produtividade e performance -- não que não se possa ter performance com ORM... mas aí acho que já fica off-topic.

*Quanto a geração de código (binaries na verdade): não gero POCOs, gero boring/repetitive/error prone/boilerplate code a partir de POCOs, que foram escritos a mão.

Há dois geradores:

- Hosts para robôs -- pouca coisa, nem vou me aprofundar agora.

- Para o app facade (compatível com WCF).

Dada a abrangência do WCF, não investiguei todas as limitações da compatibilidade, e nem pretendo, mas é certeza que existem, principalmente pra quem precisa usar SOAP, WS-*, etc. No entanto para os casos comuns, com WebHttpBinding (REST style), funciona bem. Quando não atender, para 20% (estimativa motivadora) da solução comum, é possível avaliar se vale a pena adaptar o gerador ou mesmo fazer o by pass, enquanto os outros 80% tiveram seu desenvolvimento alavancado: proposta de produtividade.

O que é gerado é um application facade: expõe algumas operações, que podem expor DTOs -- o que não envolve comportamento... se houver comportamento/estado deve ficar dentro da camada de aplicação, hand-made: Domain Model, Active Record ou Data-Driven XPTO fica a critério de quem está construindo a aplicação -- lembrando que só há "modelo anêmico" quando alguém se propõe a criar um Domain Model e não o faz direito, quando se usa outra abordagem conscientemente não é justo chamar de anêmico :), o que também já vale uma thread a parte, uma vez que o P1 não encoraja nenhum nem outro: flexibilidade.

Os DTOs podem ser gerados a partir de models, basta expor models na assinatura das operações dos application services que o gerador vai usá-los como metadadado para criar os DTOs correspondentes -- os serviços gerados vão delegar as operações para esses métodos.

Muitas vezes (!= sempre) um model (excluindo-se métodos) já serve como DTO, pronto. Ou então é só suprimir algumas properties e pronto: temos um ótimo DTO. O gerador cria um DTO a partir do formato do model correspondente. A implementação do serviço façade gerado trata do mapeamento model <-> DTO -- usando o AutoMapper, que é otimizado.

Talvez quem precise distribuir a app esteja convencido, mas e quem não precisa?

Nesse caso, como comentei na resposta ao Ricardo, o projeto pode ser beneficiado:

1 - O design de um serviço pensado para uso remoto provê uma boa separação de responsabilidades entre presentation layer e app layer, mesmo sem distribuição, IMO, o que viabiliza:

2 - Serviços/operações podem ser consumidos tanto pelos controllers como via JS/Ajax. No segundo caso WCF/REST substitui MVC "data actions" <- não gosto muito, prefiro expor WCF.

(Há maiores detalhes sobre motivação e uso no Documentation.txt)

Eu chamei de framework arquitetural pq não sei como chamar algo que se propõe a servir de base a uma solução -- se soubesse de outra alternativa não teria feito dada a desconfiança que gera. Eu também sempre tive essa "neura" com arquitetura de caixinha -- tenho! ninguém quer trabalhar com o Maker :) --, no entanto é impossível não ter vontade de reusar algumas coisas ao longo do tempo, e se vc juntar acho que há uma grande de sair uma espécie de "arquitetura pronta"... e eu não gostaria de ter que reescrever mais uma vez *nada* do que está ali -- evoluir ou adaptar ok - seja pra usar full ou só um ou outro componente.

Já indo além do que você colocou, mas aproveitando o contexto, para avisar quem estiver de passagem:

Na minha opinião -- importante receber e processar de maneira crítica a opinião dos pais -- esse projeto oferece um equilíbrio produtividade/"engessabilidade" razoável para vários projetos, mas não está livre de chatear ninguém, por isso não recomendo que ninguém use sem testar, depurar, e entender/avaliar de acordo com seus próprios critérios como as coisas estão organizadas, entender os conceitos e as libs, possibilidades de adaptação caso o projeto em questão necessite... Outro ponto importante é acho injusto alguém utilizar, conseguir alavancar 80% do desenvolvimento e depois ficar reclamando pq teve alguma dificuldade em casos fora do padrão: de um by pass na infra e faça "na mão" como teria feito de qualquer maneira ou faça um fork e adapte às suas necessidades -- o projeto não é grande.

Bruno Fiorentino

unread,

Feb 7, 2012, 5:31:45 PM2/7/12

to dotnetar...@googlegroups.com

Ricardo,

1) O que chama de Service seria o mesmo que muitos chamam de Repositório. Seria apenas para acessar o banco ou colocaria alguma regra de negócio neste serviço?

Não é repositório. É um Application Service. Delimita transações e orquestra outros componentes de negócio, incluindo repositórios, se você usa esse padrão.

2) Aonde faria uma validação do tipo não permitir a criação de dois produtos com o mesmo número ( Number ), no Service ? Gostaria de fazer validação via consulta do NHibernate e não usar por exemplo o um índice no banco de dados.

Fica a teu critério como e quando encapsular queries e regras de negócio. A única coisa que o projeto te obriga a fazer, da maneira como as coisas estão organizadas, é manter o atributo NHSession -- ou NHTransaction -- na operação do serviço. Quando um método de um componente que encapsula uma query, por exemplo, for executado o contexto estará disponível -- basta chamar NHContext.Session na implementação deste componente.

2012/2/7 Ricardo <rs...@usa.com>

Vinicius Quaiato

unread,

Feb 8, 2012, 5:05:45 AM2/8/12

to dotnetar...@googlegroups.com, dotnetar...@googlegroups.com

Não li o código, mas a primeira vista achei demasiado carregado de coisas... Coisas que eu questiono MUITO o quão necessárias são.

A promeira vista me pareceu um monte de coisas que não vanos usar mas que está ali pq é bonito.

E estou dizendo isso como quem desenvolve projetos em .Net e outras plataformas sem 1/3 do que está ali.

Mas, como disse, ainda não li o código...

Att,

Vinicius Quaiato

Enviado via iPhone

Daniel Moreira Yokoyama

unread,

Feb 8, 2012, 5:58:55 AM2/8/12

to dotnetar...@googlegroups.com

Bruno,

Beleza... já deu pra chegar à conclusão solicitada.

Não é bala de prata. (e eu só estou dizendo isto por que você deixou claro que esta era a motivação).

No mais, pelos equívocos a respeito de POCO e geração de código, só posso pedir desculpas por não ter lido com detalhes os txt's. Mas sabe como é, né... huahuahuhua

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Bruno Fiorentino

unread,

Feb 8, 2012, 11:48:32 AM2/8/12

to dotnetar...@googlegroups.com

Tudo está em uso. Nada está ali "pq é bonito". Mas acho que há bastante espaço para questionar o uso/aplicação, aprovar/reprovar, considerar alternativas ou mesmo a remoção:

Castle Windsor: permeia toda a solução, além do core IoC/DI (mais xtras do container), provê suporte para vincular os 3 interceptors (AOP, só métodos) aos componentes de um projeto. Os interceptors tratam de questões boring/error prone/boilerplate que só "sujam" o sistema quando não estão centralizadas de alguma maneira: #1 logging básico de unhandled exceptions, #2 session/transaction e #3 authorization). Contudo é possível acessar diretamente as libs adjacentes quando o mecanismo AOP engessa uma situação específica, mas na maioria dos projetos, na maioria dos casos... 80/20 é a proposta.

NHibernate, FluentNHibernate, NHibernate.Validator: além do core de ORM, há um utilitário de linha de comando que orquestra/usa os 3 para gerar a base a partir do model. FluentNHibernate mata os XML mappings. O NHibernate.Validator, além permitir validação de input (tipo System.ComponentModel.DataAnnotations), funciona integrado com o SchemaExport do NHibernate, então [Length(123)] public string Name já serve de metadado para criar Name NVARCHAR(123) sem nos preocuparmos com isso nos mapeamentos/overriding de mapeamentos, deixando mais coisas no Automapping da FluentNHibernate.

Rhino.Security: é difícil uma app não precisar tratar autorização. Essa lib é um bom começo, IMO... não só isso, é mais poderosa e simples que muita coisa feita em casa (não que não se possa fazer, mas falo no sentido de atender apenas um determinado projeto, pior ainda quando atende mal) que já vi por ai. De qualquer forma, é fácil não usá-la se requerido/desejado, mas mesmo sem ela, ainda gosto bastante do tratamento declarativo para tratar o "current user".

ManyConsole/NDesk.Options <- Compilada no Mono como Mono.Options. Todos os utilitários (são 3) de linha de comando (Console Applications) utilizam essas libs para fazer o tratar parâmetros de entrada -- string[] args. Sem elas, a vida fica difícil... Ficar manipulando o array direto (tratar key/value pairs, switches, obrigatoriedade) para 1 console já é ruim, para N consoles é um inferno: desencoraja automatizar as coisas, faz a gente desistir. Eu havia começado uma, mas não estava satisfeito e não queria mais investir tempo nisso, então encontrei essas libs. Fiquei muito feliz!

App Facade generation/WCF: Sem distribuição, acho que vale a pena pela organização e pela capacidade de expor um mesmo serviço tanto para Controllers como para JS/AJAX, matando MVC "data actions". MVC fica pra tratar delivery de HTML, fluxo de navegação. Apesar do MVC facilitar testes, acho melhor testar POCOs -- o app layer exposto pelo facade, já o facade (que é gerado) não precisa de testes. Com distribuição, além do consumo JS/AJAX, fica fácil *desenvolver num processo só (sem attachar outros processos, quando é necessário depurar): isso é muito chato, faz perder velocidade. Para *homolog/prod, obviamente, fica distribuido. Mas é bom "ligar o WFC" em dev de vez em quando pra pegar/tratar problemas de serialização.

Bot hosting generation: Já trabalhei em projetos em que não foi necessário um robô sequer. Agora, quando você precisa de vários robôs o negócio começa a complicar... Na verdade, não é "complexo", mas é um monte de trabalho braçal que eu quis varrer da face da terra pra nunca mais ter que encarar (ok, se for para estender o gerador). Implemento Start(); Stop(); nos Bots POCOs e um gerador cria um host console (dev) e um host windows service (homolog/prod) pra mim. Pronto.

"Typed" AppSettings: Uma solução muito simples baseada em Castle Dynamic Proxy/NHibernate.Validator, para fazer parsing e validação de AppSettings. Em alguns projetos a quantidade de chaves é enorme, e começa a chatear/atrasar a vida: "AppSettings Hell". Além de alavancar o desenvolvimento, já vi equipes de QA tendo que reiniciar um roteiro de testes, estando quase no final, por que o parsing/validação de um dos parâmetros falhou. Muito chato/improdutivo, mesmo pq eles vão te procurar :( O componente em questão resolve esse problema.

Log4Net: log? sempre. Log4Net tem um mecanismo baseado em hierarquia (pode ser hierarquia de namespaces) que reduz bastante a quantidade de configuração necessária.

*Bem, nada está aí por acaso.

Em outras linguagens/plataformas talvez seja possível resolver esses problemas de outras maneiras -- ou mesmo não ter esses problemas --, mas nessa solução o foco é C# como linguagem principal -- e eu deveria ter substituído .NET por C# na descrição do projeto/subject do post, pra facilitar a vida de possíveis reviewers :)

Antes de partir de vez para os interceptors, eu tentei favorecer higher-order functions, tuples, mas putz, sinceramente, acho que essas coisas não escalam muito bem em C#. Estão mais para um "vernis". São muito importantes e agregam valor em várias APIs, reduzindo o número de implementações de 1 método, melhoram muito a expressividade, além de servir de base a bibliotecas muito bem feitas e importantes como LINQ e a TPL, mas numa aplicação/arquitetura de aplicação umas coisas estranhas começam a "surgir": Func<Tuple<string,Dictionary<.... .... .... , bool> ... ;;; .Item1, .Item2, .Item3 é feio... a inferência não ajuda muito se vc começa a "usar de verdade", fica muito verboso, não tem packing/unpacking de nada (quem sabe no C# 6.0?)... então fiquei nas soluções mais comuns para alavancar OOP mesmo. Talvez esteja errado, mas enfim: IMO.

Talvez com Python ou F# a estória teria sido diferente, pois são outros paradigmas -- tomando a licença para promover o dinamismo do Python à "outro paradigma".

Se tiver um tempo para revisar e emitir sua opinião e propor alternativas tanto para a abordagem geral como para pontos específicos -- os "highlights" acima, entre outros pontos que lhe chamem atenção -- eu agradeceria :)

2012/2/8 Vinicius Quaiato <vinicius...@gmail.com>

daniel carli

unread,

Feb 8, 2012, 12:02:11 PM2/8/12

to dotnetar...@googlegroups.com

Mas o foda de tudo isso é que vc nem começou a codar e seu proj já ta parecendo uma arvore de natal.

Daniel Carli

Bruno Fiorentino

unread,

Feb 8, 2012, 12:04:52 PM2/8/12

to dotnetar...@googlegroups.com

Mas o foda de tudo isso é que vc nem começou a codar e seu proj já ta parecendo uma arvore de natal.

Pode ser sua opinião final, mas eu sugiro vc ler a os txts e dar uma olhada na implementação antes de formá-la e gritar "AÊ ASTRONAUTA" da janela, de passagem.

[]s

2012/2/8 daniel carli <dansa...@gmail.com>

Fabiano França

unread,

Feb 8, 2012, 12:10:50 PM2/8/12

to dotnetar...@googlegroups.com

Bruno,

Acredito que você já tenha dado uma olhada no SharpArchitecture. Algum motivo para não adotar ele?

[1] https://github.com/sharparchitecture/Sharp-Architecture

Um abraço.

Bruno Fiorentino

unread,

Feb 8, 2012, 12:19:26 PM2/8/12

to dotnetar...@googlegroups.com

A SharpArch foca em ASP .NET MVC e DDD. Estou tentando ser neutro (Domain Model ou não é uma escolha), menos "opinionated", menor e ao mesmo tempo cobrir mais coisas: distribuição, robôs.

Não gosto muito daquele conceito/implementação de DomainSignature. O equivalente está no SampleProject, tentei simplificar, seguindo a orientação que encontrei no NHForge.org.

... mas é um ótimo trabalho -- e já é bem maduro comparado ao meu.

[]s

2012/2/8 Fabiano França <fab...@algumasideias.net>

Daniel Moreira Yokoyama

unread,

Feb 8, 2012, 12:37:03 PM2/8/12

to dotnetar...@googlegroups.com

Bruno,

O que o Quaiato quis dizer com estar aí pq é bonito não é questionando se está sendo utilizado ou não, mas questionando se é necessário ou não.

Volto a dizer que vc pré-definiu um stack que acumula complexidade com coisas que você deveria evitar usar até que fôsse realmente necessário.

Arquitetura de software é tomada de decisões que são difíceis mudar depois. Então você posterga a decisão até o último momento sensato.

Por exemplo, se o System Of Records for algo que está sendo deixado pra ser definido por último, é um erro enorme assumir que a ferramenta a ser usada será o nHibernate. E isso é só pra exemplificar. Tem uma porção de coisas que podem não ser úteis, e usá-las em um stack é assumir muita coisa prematuramente.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Em 8 de fevereiro de 2012 14:48, Bruno Fiorentino <bruno.fi...@gmail.com> escreveu:

Bruno Fiorentino

unread,

Feb 8, 2012, 12:52:10 PM2/8/12

to dotnetar...@googlegroups.com

Daniel, esse tipo de análise deve ocorrer antes de considerar essa solução.

Então vamos assumir que a "brincadeira com a bala de prata" foi uma espécie de trocadilho marketeiro, mas mesmo na brincadeira: "não existe bala de prata".

Então aqui está uma oportunidade para enfatizar: antes de considerar essa stack, é preciso querer/precisar usar ORM, por exemplo. Não só ORM, mas todo ou quase todo o resto (IoC/DI, etc.) em conjunto. Caso contrário, antes de partir pra outra, como não é exatamente tudo ou nada, restam as seguintes alternativas:

- Dar um unload nas libs q não lhe interessam e, se não quebrar nada -- em vários casos não quebra --, seguir em frente *mais leve*. Homework de quem se interessar. Não criei todas as possibilidades de SampleProject, nem pretendo.

- Extrair um componente ou outro que agregue valor na sua solução "custom". O código está disponível.

Eu mesmo penso em consumir esses componentes dessas 3 maneiras.

[]s

2012/2/8 Daniel Moreira Yokoyama <moreira....@gmail.com>

Winston Pacheco Junior

unread,

Feb 8, 2012, 12:55:33 PM2/8/12

to dotnetar...@googlegroups.com

Daniel,

Mas se você pensar só em Abstração pra CRUD, tipo, CRUD basicão mesmo. Pra mim nHibernate já é abstração o suficiente. Não criticando a arquitetura do brother, deve ter sua utilidade no momento de alguma necessidade específica, sei lá, na hora de distribuir a aplicação, enfim. Você não vai ter trabalho com nenhuma coisa repetitiva simples e se precisar filtrar por algum campo, tá feito também.

Ainda não vi o código, mas se eu respondesse a primeira pergunta que você fez a Bruno, seria: nHibernate é suficiente pro CRUD, o resto fica por conta da diversão que as pessoas precisam pra continuar vivendo =D

Vinicius Quaiato

unread,

Feb 8, 2012, 1:38:00 PM2/8/12

to dotnetar...@googlegroups.com

se há necessidade de explicar tanta coisa assim:

1 - a concepção não está boa

2 - o intento não é claro

apenas meu ponto de vista.

Daniel Moreira Yokoyama

unread,

Feb 8, 2012, 1:42:33 PM2/8/12

to dotnetar...@googlegroups.com

Bruno,

A melhor coisa que vc pode fazer é não considerar nada disso antes da hora em que se perceba ser o momento de decidir.

Não há, ao meu ver, nenhuma situação segura onde se pode assumir tudo isto num projeto. Em qualquer situação isto é assumir uma complexidade que pode não ser necessária.

Pra esclarecer, enfatizo:

NÃO HÁ ocasiões em que se possa assumir tudo isto com segurança sem correr o risco de não avaliar complexidade desnecessária embutida em toda a solução proposta.

Reenfatizo: NÃO HÁ.

Se considerar que há exceção, já comecei errado.

Se eu partir do princípio de que vou precisar de tudo isto, já estou começando errado. Pois estou assumindo coisas que sem avaliar a real necessidade e/ou sem avaliar a melhor forma de usá-la no contexto.

Fora de contexto, eu acabo criando só um pretexto pra usar isso tudo.

Só quando eu contextualizo, ou seja, crio o cenário perfeito pra decidir se vou precisar de uma ferramenta, é que eu a escolho. Isto é, se não preciso pensar em persistência agora, não vai ser agora que vou escolher o ORM (até pq, posso não precisar de um no fim das contas).

Pré-assumir algo é tomar uma decisão que não precisava ser tomada, pelo menos por ora. E a decisão tomada pode comprometer minha arquitetura.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Daniel Moreira Yokoyama

unread,

Feb 8, 2012, 1:43:54 PM2/8/12

to dotnetar...@googlegroups.com

Winston,

Mas não estamos querendo fazer CRUD, queremos?

Do contrário se torna insensato discutir arquitetura.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Bruno Fiorentino

unread,

Feb 8, 2012, 2:03:51 PM2/8/12

to dotnetar...@googlegroups.com

Daniel, não vou dizer que você esta certo, nem errado. É sua maneira de trabalhar/ver as coisas. E acho que, nessa linha de trabalho, fica difícil você usar da primeira ou mesmo da segunda maneira que descrevi. Talvez da terceira...

*No meu caso, acredito que é possível assumir algumas coisas e -- se não houver nenhuma razão específica para descartar X ou Y, que eventualmente não são ferramentas muito intrusivas -- seguir em frente com uma certa tranquilidade. Até pq se a estrutura que escolhida favorece a separação de a) infraestrutura de b) negócio (via POCOs) -- obviamente requer uma boa execução do projeto tb -- fica relativamente fácil adaptar ou mesmo portar para outra arquitetura, a "certeira", quando a incerteza acabar.

Além disso, vira filosofia... casos concretos (envolvendo o negócio, requisitos funcionais e não funcionais, cultura organizacional, skills da equipe, entre outros fatores) podem se beneficiar de uma ou outra abordagem, sem é muito fica difícil precisar.

Esse projeto não resolve esse tipo de questão, fica a cargo de quem avalia.

É só um one-man show, de boa vontade, retribuindo alguma coisa num ecossistema oss ainda nascente (.NET) que, tomara, não tenha chegado ao ápice, com algum software que pode vir a ser útil, como um todo ou em fragmentos. Caso outras pessoas gostem, se interessem, critiquem, usem e tal pode vir a ser algo mais. Se não, beleza, fica só uma divisão publica da toolbox do Brunão, por acaso aí na internet, correndo o risco de empoeirar.

Winston Pacheco Junior

unread,

Feb 8, 2012, 2:08:45 PM2/8/12

to dotnetar...@googlegroups.com

Daniel,

Falei do CRUD pois foi onde ele explicou que a arquitetura teria o maior ganho, teve um percentual que eu perdi em algum lugar (e olha que eu gosto tanto deles).

Enfim, toda essa discussão é inútil partindo da idéia do BDUF. Na minha concepção você está correto em suas colocações. Também não sou a favor de arquitetura pra demonstrar tecnologia, que é o que fica parecendo num projeto como esses. Sem um problema que justifique o uso da mesma, acho que isso atrapalha muita gente, principalmente iniciantes.

Ainda assim, eu gosto de ver o que o povo pensa sobre o uso da tecnologia.

Bruno Fiorentino

unread,

Feb 8, 2012, 2:26:37 PM2/8/12

to dotnetar...@googlegroups.com

Bom falar sobre Big Design Up Front. Aproveitando um trecho que escrevi em outra resposta, aqui está como atacar BDUF se houver algum interesse em utilizar essa solução:

Então aqui está uma oportunidade para enfatizar: antes de considerar essa stack, é preciso querer/precisar usar ORM, por exemplo. Não só ORM, mas todo ou quase todo o resto (IoC/DI, etc.) em conjunto. Caso contrário, antes de partir pra outra, como não é exatamente tudo ou nada, restam as seguintes alternativas:
- Dar um unload nas libs q não lhe interessam e, se não quebrar nada -- em vários casos não quebra --, seguir em frente *mais leve*. Homework de quem se interessar. Não criei todas as possibilidades de SampleProject, nem pretendo.
- Extrair um componente ou outro que agregue valor na sua solução "custom". O código está disponível.
Eu mesmo penso em consumir esses componentes dessas 3 maneiras.

UNLOAD seguido de REMOVE.

[]s

2012/2/8 Winston Pacheco Junior <winston...@gmail.com>

Juan Lopes

unread,

Feb 8, 2012, 3:02:30 PM2/8/12

to dotnetar...@googlegroups.com

Ainda não tive oportunidade de ler o código, mas deixe-me explicar porque sou contra frameworks como o seu, Bruno.

Eu tenho um framework desses no meu github. Por muito tempo achei que ele realmente aumentava a "produtividade" dos desenvolvedores que o usavam. Até que eu percebi que eu usava esse código porque trabalhava numa consultoria que se gabava por fazer boot de projetos muito rápido. E não eram os projetos em si que precisavam do framework. A empresa que eu trabalhava é que precisava. Os projetos não eram todos no mesmo molde, tampouco eram combinações dos bloquinhos do framework. Nós só o usávamos porque era o único martelo que tinhamos.

Comecei a perceber o quanto frameworks arquiteturais eram ruins quando percebi que não usava o que eu mesmo havia feito para os meus projetos. Quando percebi que o framework me limitava a um design pré-pensado. Que era mais útil para programadores que tem preguiça de modelar. Mais ainda, quando eu percebi que as bibliotecas que eu achava tão lindas no começo, já não eram tão mais lindas assim.

Com o tempo, todos nós evoluímos enquanto programadores. Os frameworks tem mais dificuldade de evoluir.

No mais, Bruno, imagino que o seu framework resolva muito bem alguns problemas que você experienciou como programador. Tenho certeza que você ajudará muito mais se expuser essas soluções de forma a não obrigar a seguir o mesmo design que você imaginou. Eu por exemplo detesto service layer, e taco pedra com força no WCF. Nunca usarei o seu framework. Por outro lado, eu posso gostar da sua solução de gerência de sessões e transações com o NHibernate. Mas eu continuarei não usando o seu framework.

Entende o problema?

2012/2/8 Bruno Fiorentino <bruno.fi...@gmail.com>

Antonio Pedro

unread,

Feb 8, 2012, 3:35:18 PM2/8/12

to dotnetar...@googlegroups.com

clap! clap! clap!

From: m...@juanlopes.net
Date: Wed, 8 Feb 2012 18:02:30 -0200
Subject: Re: [dotnetarchitects] P1 - Architectural framework for .NET based solutions
To: dotnetar...@googlegroups.com

Bruno Fiorentino

unread,

Feb 8, 2012, 4:25:28 PM2/8/12

to dotnetar...@googlegroups.com

Se em algum momento vc evoluir ou adaptar substanciamente um ou outro componente e isso não for nada que comprometa o seu trabalho/negócio no que tange a vantagem competitiva e questões relacionadas e puder compartilhar, ficaria muito grato.

Talvez eu quebre em projetos/repositórios menores mais pra frente, como você sugeriu, sem dar ênfase ao uso do conjunto todo, e chamar de "framework arquitetural", mas ainda quero estabilizar. De qualquer forma já está ficando meio chato a emissão de opiniões iniciando com "parêntese mais ainda não li nada fecha parêntese". Não é muito grande, não custa muito...

Os projetos não eram todos no mesmo molde, tampouco eram combinações dos bloquinhos do framework. Nós só o usávamos porque era o único martelo que tinhamos.
Comecei a perceber o quanto frameworks arquiteturais eram ruins quando percebi que não usava o que eu mesmo havia feito para os meus projetos. Quando percebi que o framework me limitava a um design pré-pensado. Que era mais útil para programadores que tem preguiça de modelar. Mais ainda, quando eu percebi que as bibliotecas que eu achava tão lindas no começo, já não eram tão mais lindas assim.
Com o tempo, todos nós evoluímos enquanto programadores. Os frameworks tem mais dificuldade de evoluir.

Nos trabalhamos em cima de uma pilha de abstrações, cada vez maior, de qualquer forma. E criamos as nossas. E em alguns casos vale a pena reusar. As pessoas podem ser preguiçosas e acomodadas tanto usando ".NET/C#/BCL puros" como acomodadas ao escolher determinadas ferramentas/abstrações para começar um projeto, dá no mesmo, é uma questão de natureza humana, não é "culpa" da tecnologia. Já enfatizei diversas vezes: entendam o que os componentes se propõe a fazer antes de usar. Quem ignorar esse conselho vai assumir o risco. Mas se estender muito sobre isso é querer ensinar como as pessoas devem viver.

Quanto obsolescência, tudo está sujeito. A empresa que entra no "modo linha de produção" está correndo mais risco de qualquer maneira com C com .NET puro ou com as bibliotecas que usei as que criei no topo. Agora, se a toma os devidos cuidados antes de iniciar *cada* projeto, não há problema. Mas isso está fora do escopo do que me proponho a ajudar com alguns componentes escritos em C#, é mais uma questão de negócio/estratégia/operação... Na verdade publiquei algumas coisas que me ajudam ou ajudaram, em contextos diversos, fica a cargo de cada um avaliar por seus critérios, a cada novo projeto, enfatizo novamente. Mas isso também é outra coisa que considero meio fora do escopo, é mais uma atitude, comportamento que cada um ou cada empresa pode ou não cultivar e que vai ser um fator importante para determinar seu sucesso em inúmeras áreas, além de tecnologia. *Eu só queria discutir pontualmente as features do projeto*. Novamente, se aprofundar nisso sem um exemplo concreto de aplicação vira filosofia, querer ensinar como viver ou tocar um negócio... bem, eu vejo assim.

WCF... a ferramenta está aí, acho que tem valor, não acho ruim, mas o .NET está ficando cada vez mais fragmentado, o que é bom, temos alternativas :)

[]s

2012/2/8 Juan Lopes <m...@juanlopes.net>

Juan Lopes

unread,

Feb 8, 2012, 8:58:44 PM2/8/12

to dotnetar...@googlegroups.com

Tudo bem, entendo sua colocação.

Realmente, filosoficamente eu sou sou contra highly-coupled business frameworks. Mas já expus isso no email passado. Só não estou entendendo a revolta do Quaiato, sendo que ele usa Ruby "em arreios".

Mas vamos começar por algumas bases.

Se sua session é uma propriedade static do NHContext, como você testa suas queries isoladamente?

namespace SampleProject.Data.Queries.Models.UserModel {

public class UserByEmailAndPasswordQuery : IUserByEmailAndPasswordQuery {

User IUserByEmailAndPasswordQuery.Execute(string email, string pwdHash) {

var user = NHContext

.Session.QueryOver<User>()

.Where(x => x.Email == email).And(x => x.PwdHash == pwdHash)

.List().SingleOrDefault();

return user;

}

2012/2/8 Bruno Fiorentino <bruno.fi...@gmail.com>

Daniel Moreira Yokoyama

unread,

Feb 8, 2012, 9:02:07 PM2/8/12

to dotnetar...@googlegroups.com

O Quaiato usa rails????

huahuauhauhhua...

Nada contra... mas aí nem vale questionar o stack do Bruno.

huauhauhauhauha

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Bruno Fiorentino

unread,

Feb 8, 2012, 9:04:46 PM2/8/12

to dotnetar...@googlegroups.com

Pode questionar sim, ficaria agradecido com um review :)

2012/2/9 Daniel Moreira Yokoyama <moreira....@gmail.com>

Juan Lopes

unread,

Feb 8, 2012, 9:04:33 PM2/8/12

to dotnetar...@googlegroups.com

Sobre código:

Outro ponto, sua classe Entity<TId> sobrescreve GetHashCode mas não sobrescreve Equals. Isso é conceitualmente errado, não?

Além disso, você faz cache de hashCode, sendo que seu id não é imutável.

E não entendo o propósito da interface ITestableEntity. Se você quer deixar o id como membro privado, basta prover uma implementação consistente de Equals e GetHashCode, certo?

2012/2/8 Juan Lopes <m...@juanlopes.net>

Daniel Moreira Yokoyama

unread,

Feb 8, 2012, 9:07:24 PM2/8/12

to dotnetar...@googlegroups.com

Foi mal Bruno, com certeza pode... só quis trollar o arrobinha.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

https://github.com/bfiorentino/P1/blob/master/src/P1/P1.Tests/NHibernate/NHSessionInterceptorTests.cs

Stay Sharp!

Bruno Fiorentino

unread,

Feb 8, 2012, 9:10:53 PM2/8/12

to dotnetar...@googlegroups.com

Mal nada, vamos manter a thread nos "trilhos" hehehe #troll

Bruno Fiorentino

unread,

Feb 8, 2012, 9:18:13 PM2/8/12

to dotnetar...@googlegroups.com

A property é statica, para facilitar o consumo, mas para testar podemos inicializar assim:

      NHSessionManager nhSessionManagerStorage = null;


      NHSessionManagerInitializer.Initialize(
        new InlineableStorage<NHSessionManager>(
          () => nhSessionManagerStorage, value => nhSessionManagerStorage = value));

No Global.asax, fica assim:

var nhSessionManagerKey = "..."

  NHSessionManagerInitializer.Initialize(
            new InlineableStorage<NHSessionManager>(
              () => (NHSessionManager)HttpContext.Current.Items[nhSessionManagerKey],
              value => HttpContext.Current.Items[nhSessionManagerKey] = value));

Achei mais simples a static property nesse caso, muito corriqueiro, do que registrar no container e ficar injetando sempre.

2012/2/8 Juan Lopes <m...@juanlopes.net>

Bruno Fiorentino

unread,

Feb 8, 2012, 9:47:05 PM2/8/12

to dotnetar...@googlegroups.com

Desculpe pela formatação ruim, aqui vc encontra esses exemplos:

https://github.com/bfiorentino/P1/blob/master/src/SampleProject/SampleProject.Site.Host/Global.asax.cs

https://github.com/bfiorentino/P1/blob/master/src/SampleProject/SampleProject.App.Host/Global.asax.cs

2012/2/9 Bruno Fiorentino <bruno.fi...@gmail.com>

Bruno Fiorentino

unread,

Feb 8, 2012, 10:17:37 PM2/8/12

to dotnetar...@googlegroups.com

Sem problemas quanto ao Equals, é sobrescrito na base (Model), e o GetHashCode da Entity é consistente com ele, tanto que o warning relacionado nem é feito pelo compilador nesse caso.

O Id deve e vai ser protected. É uma "inconsistência temporária" -- mudei para public durante o desenvolvimento do CRUD de exemplo... acho que havia algo relacionado ao AutoMapper. Preciso retomar e resolver.

ITestableEntity é justificada pelo método BaseGetHashCode(), necessário para os testes, voltando ao Id protected, para o Id também.

O membro privado e parte da implementação que segue essa orientação: http://nhforge.org/wikis/patternsandpractices/identity-field-equality-and-hash-code.aspx

Foi a proposta que achei mais simples para implementar "NHibernate Aware GetHashCode/Equals".

Mas o fato disso estar no SampleProject é justamente, facilitar o início porém não forçar ninguém com algo compilado no P1. Nesse caso, achei válido deixar aí... mas quase ficou lá :)

[]s

2012/2/9 Juan Lopes <m...@juanlopes.net>

Vinicius Quaiato

unread,

Feb 9, 2012, 6:28:18 AM2/9/12

to dotnetar...@googlegroups.com

bom... nem vou entrar nos méritos do Rails. Não entendo que um "erro" justifique outro.

Meu ponto é: o framework deve falar por si só. Se eu preciso ler TODO FONTE pra entender isso, desculpe mas tá ruim.

Exemplo? http://nancyfx.org/

Não li nem uma vírgula de código fonte, e pronto.

Acho que o ponto aqui não é nem o *como* o framework foi construído(por isso eu não li seu fonte) mas o *por quê*.

Bruno Fiorentino

unread,

Feb 9, 2012, 11:52:43 AM2/9/12

to dotnetar...@googlegroups.com

Motivação:

The motivation to build P1 was to provide a simple, lightweight and productive architectural framework for .NET based solutions -- not only for web/frontend. P1 aggressively automates repetitive tasks helping to reduce error prone and boilerplate code (...)

The design mindset regarding P1 features was they should be useful for at least 80% of a solution built on top of it and unused features should get out of the way. P1 can be seen as a tool box. Most features are optional/skippable. The full feature set is recommended, but dependencies were minimized, this way choices can be made or components can be easily extracted and adapted.

O README.txt do projeto, de onde extraí o texto acima, contém mais detalhes. Não é "twit sized" como a home page do nancy.org, que é uma lib ultra especializada, o que não tira o mérito da concisão, mas convenhamos que ajuda. O README.txt poderia ser ainda menor -- é algo que vou considerar de maneira um tanto descompromissada pois a minha prioridade para os próximos passos, a medida que o meu tempo livre permitir, é desenvolver/estabilizar tais componentes -- mas é menor que muitos blog posts que vemos por aí e que não são necessariamente ruins ou sem foco só por causa do "word count".

A rede de modo geral nos oferece muita coisa boa, de maneira sem precedentes, mas às vezes é preciso fazer um pouco de "mining", investir alguns minutos, por vezes algumas dezenas deles, nem tudo está de bandeja, principalmente num primeiro momento. Com base nessa constatação me permito o "comodismo" de "jogar um código no github" e fazer um README meio grande, não criar mais respositórios/libs agora, apesar de clamar "a modularização é boa" -- modularização que pode vir a ser melhorada se outras pessoas avaliarem, facilitando a criação de repositórios/libs ultra especializados como o NancyFx no futuro, beneficiando a todos com mais *alternativas para trabalhar com C#, a partir desta(s) pequena(s) contribuição(ções).

Um colega me mandou um e-mail em PVT, dizendo que até o momento estava gostando de alguns conceitos/implementações do projeto, mas que o projeto violava o conceito de arquitetura evolucionária/emergente. Para quem segue a risca os princípios, acho que o projeto hoje "AS IS" ainda pode vir a ser útil:

(...) P1 can be seen as a tool box. Most features are optional/skippable. The full feature set is recommended, but dependencies were minimized, this way choices can be made or components can be easily extracted and adapted. (...)

Evolucionário? Não saia programando dentro projeto, mas durante e evolução de sua arquitetura evolucionária/emergente, que começou com a "solution vazia", é possível que vc extraia e adapte componentes que lhe ajudem a seguir nesse processo ou modelo conceitual/mental de trabalho, sei lá como chamar. Esse problema/decisão/mindset está além do que me proponho a ajudar compartilhando alguns componentes escritos em C#, como já mencionei anteriormente em questões relacionadas. O que está alinhado com o que comentei sobre BDUF anteriormente:

Então aqui está uma oportunidade para enfatizar: antes de considerar essa stack, é preciso querer/precisar usar ORM, por exemplo. Não só ORM, mas todo ou quase todo o resto (IoC/DI, etc.) em conjunto. Caso contrário, antes de partir pra outra, como não é exatamente tudo ou nada, restam as seguintes alternativas:
- Dar um unload nas libs q não lhe interessam e, se não quebrar nada -- em vários casos não quebra --, seguir em frente *mais leve*. Homework de quem se interessar. Não criei todas as possibilidades de SampleProject, nem pretendo.
- Extrair um componente ou outro que agregue valor na sua solução "custom". O código está disponível.
Eu mesmo penso em consumir esses componentes dessas 3 maneiras.

UNLOAD seguido de REMOVE.

Alem do README.txt e do Documentation.txt, já entrei em maiores detalhes/motivações sobre as features numa mensagem anterior.

Quando a gente "joga" algo no github, ou publica um "respeitável e impecável projeto", estamos expondo algo ao mundo. Ao mundo real. No mundo real há empresas/equipes/pessoas "tradicionais", empresas/equipes/pessoas "+ou- agile" (sejam preguiçosas/relaxadas ou engajadas em evolução, sei lá) -- que é um grande mercado para consultoria, diga-se de passagem -- além de empresas/equipes/pessoas "realmente agile".

Acho que os 3 grupos podem se beneficiar desse trabalho... está fora do meu controle/círculo de influência ou mesmo responsabilidade como usam/aplicam tanto os componentes que criei como está fora o que fazem com Windows, Linux, Java, .NET, a SharpArchitecture ou o Ruby On Rails. Tratamento em doses homeopáticas ou injeção logo pq não quer ficar tomando comprimidos de 6 em 6 horas? Sei lá! Não vou ensinar ninguém a viver ou gerir negócio/estratégia/operação com alguns componentes escritos em C# que se propõe a "aumentar produtividade".

Como disse anteriormente trabalhamos numa pilha crescente de abstrações. Qualquer abstração, mesmo fora de tecnologia, se propõe a "aumentar a produtividade".

Entendo o medo dos "frameworks corporativos", eu também tenho, e creio não ter criado um monstro desses.

Fica uma reflexão: não há "solution vazia". Estamos utilizando templates, por definição pré-definidos, do Visual Studio, com bibliotecas pré-selecionadas -- e quando os uso, tenho a "mania" de deletar, manualmente, as referências inúteis, pouca gente faz isso. Então qual o problema de criar os nossos "templates"/bibliotecas, se assumimos a responsabilidade de não exagerar no tamanho, de buscar o equilíbrio, a modularização? Estamos discutindo sobre um intervalo bem pequeno, no topo da enorme pilha de abstração em que trabalhamos. Eu vejo a arquitetura evolucionária/emergente mais como um manifesto contra aberrações tecnológicas, culturas muito arcaicas com hierarquia rígidas e problemas de comunicação/fluxo de comunicação -- problemas que, fora do meu trabalho, estão além do meu controle/círculo de influência e mesmo responsabilidade. Acho o propósito válido, mas me reservo o direito de não ser purista ou seguir as risca tais princípios como se fossem mandamentos. Tento processar de maneira crítica todas essas tendências.

Não sei se ainda é possível ajudar mais quanto a motivação...

Quanto a ler "todo o código": esse é o meu conselho a quem se interessar. Quem tiver qualquer tipo de restrição (vontade, tempo, etc.), deve desencanar desse trabalho, pelo menos nessa fase inicial.

Daqui em diante, acho que quem quiser avaliar já tem background suficiente sobre a motivação e status do projeto para tratar pontos específicos, lembrando que existem vários projetos onde uma arquitetura baseada em IoC/DI/AOP e ORM vale a pena -- sugiro a quem discorda ou mesmo queira abolir o uso pular a thread ou talvez focar em outros conceitos/componentes menores que podem ser utilizados sem tais padrões e que, futuramente, podem ser distribuídos em pacotes independentes.

2012/2/9 Vinicius Quaiato <vinicius...@gmail.com>

Ricardo

unread,

Feb 9, 2012, 8:59:17 PM2/9/12

to dotnetar...@googlegroups.com

Bruno,

       Obrigado pelas respostas.

       O serviço de aplicação deve ser o que explicou em outra mensagem:

       "Ao criar esses serviços, não podemos focar em reuso na interface do serviço... eles são talhados para atender a uma tela ou módulo de telas específico, só assim conseguimos ser rápidos evitar muitas chamadas remotas, seja ao banco ou wcf. Agora, dentro dos serviços podemos explorar maneiras de promover reuso, composição, etc."

       No caso de usar apenas o MVC teria basicamente um um serviço para cada controller. Seria isso? Um serviço CRUD como no exemplo provavelmente não seria usado em outras telas ?


On Tuesday, February 7, 2012 8:31:45 PM UTC-2, Bruno Fiorentino wrote:

Ricardo,

1) O que chama de Service seria o mesmo que muitos chamam de Repositório. Seria apenas para acessar o banco ou colocaria alguma regra de negócio neste serviço?

Não é repositório. É um Application Service. Delimita transações e orquestra outros componentes de negócio, incluindo repositórios, se você usa esse padrão.

2) Aonde faria uma validação do tipo não permitir a criação de dois produtos com o mesmo número ( Number ), no Service ? Gostaria de fazer validação via consulta do NHibernate e não usar por exemplo o um índice no banco de dados.

Fica a teu critério como e quando encapsular queries e regras de negócio. A única coisa que o projeto te obriga a fazer, da maneira como as coisas estão organizadas, é manter o atributo NHSession -- ou NHTransaction -- na operação do serviço. Quando um método de um componente que encapsula uma query, por exemplo, for executado o contexto estará disponível -- basta chamar NHContext.Session na implementação deste componente.
2012/2/7 Ricardo
Bruno, 

Estou aprendendo arquitetura para Web e acho interessante o projeto para resolver algumas dúvidas que tenho.

O exemplo que tem no git parece que é um simples cadastro de um produto, abaixo pequeno trecho 

das classes que dá para outras pessoas entenderem. 


public class Product : Entity<int> {
 
    [Length(50)]
    public virtual string Name { get; set; }
    [Range(1, 100)]
    public virtual int Number { get; set; }
 
}
public class ProductsController : Controller {

    private readonly IProductsService productsService;

    public ProductsController(IProductsService productsService) {

      this.productsService = productsService;

    }

    public ActionResult Create(Product prod) {

      var id = this.productsService.Create(prod);

      return this.RedirectToAction("retrieveall");

    }
  public class DefaultProductsService : IProductsService {
 
    [NHTransaction]
    [Authorize(SecurityNames.Operations.App_ProductsService_Create)]
    public int Create(Product prod) {
      NHContext.Session.Save(prod);
      NHContext.Session.Flush();
 
      return prod.Id;
    }
Vou começar com algumas dúvidas que tenho:
1) O que chama de Service seria o mesmo que muitos chamam de Repositório. Seria apenas para acessar o banco ou colocaria alguma regra de negócio neste serviço ?

2) Aonde faria uma validação do tipo não permitir a criação de dois produtos com o mesmo número ( Number ), no Service ? Gostaria de fazer validação via consulta do Nhibernate e não usar por exemplo o um índice no banco de dados.

Ricardo

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

Bruno Fiorentino

unread,

Feb 10, 2012, 9:10:32 AM2/10/12

to dotnetar...@googlegroups.com

Ricardo, não conheço formula/padrão para essa organização -- talvez alguém mais possa ajudar. Sugiro você começar com "1 pra 1", depois, de maneira bem empírica, identificar sets de controllers que podem reusar serviços/operações. Eu já segui assim em alguns projetos e funcionou bem, mas é preciso bastante atenção, refactoring e organizar bem seus componentes nas camadas abaixo para poder reusá-los, suportando a falta de foco no reuso dos Application Services.

Depende de muitas variáveis: do que os controllers fazem, do quão "AJAX heavy" a app é, se o AJAX focam em páginas/telas completas ou widgets ou ambos... se tem mais cara de web content, e-commerce ou Line of Business (LoB)...

Como disse antes, já abri mão em grande parte do reuso da interface dos serviços de aplicação em prol de atender bem *cada UI/UX, com a menor quantidade de chamadas remotas possível (isso vale pra AJAX, ORM/DB, tudo, mesmo qdo a solution não é distribuída em web e app servers) ... em alguns casos cheguei a criar operações assim:

"SalvaABCExatamenteComoEssaTelaPrecisaERetornaAlemDoStatusOutroObjetoNaoExatamenteRelacionadoMasQueATelaPrecisaParaSeguirOFluxoDeNavegacaoSemMaisUmaChamadaRemota();"

Que são bem estranhos se analisados fora de contexto (e se vc passar um check-list de boas práticas hmmm... vai dar o que falar) mas foi como suportei/entreguei a melhor UI/UX.

Aí você precisa encontrar o ponto de equilíbrio, o que é o good enough para o seu caso...

Recomendo a leitura:

"Service Stack was heavily influenced by Martin Fowlers Data Transfer Object Pattern:
When you're working with a remote interface, such as Remote Facade (388), each call to it is expensive. As a result you need to reduce the number of calls, and that means that you need to transfer more data with each call. One way to do this is to use lots of parameters. However, this is often awkward to program - indeed, it's often impossible with languages such as Java that return only a single value.
The solution is to create a Data Transfer Object that can hold all the data for the call. It needs to be serializable to go across the connection. Usually an assembler is used on the server side to transfer data between the DTO and any domain objects."

"WCF the anti-DTO Web Services Framework
Unfortunately this best-practices convention is effectively discouraged by Microsoft's WCF SOAP Web Services framework as they encourage you to develop API-specific RPC method calls by mandating the use method signatures to define your web services API. This results in less re-usable, more client-sepcfic APIs that encourages more remote method calls."

+ http://www.servicestack.net/docs/framework/overview

Pq reduzir qq tipo de chamada remota:

+ http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing

Mais perspectiva para entender os tradeoffs relacionados a serviços (não é específico do ServiceStack.Net, muito bom!):

+ https://github.com/ServiceStack/ServiceStack/wiki/Service-Stack-Web-Services

Ver slides sobre as vantagens desse Fx:

+ https://servicestack.net

*** Vc começa a entender críticas ao/problemas do WCF e fica com mais subsídios contornar possíveis problemas nas suas soluções -- tanto na modelagem como substituindo/estendendo componentes default. O ServiceStack não é tudo ou nada, dá pra reaproveitar componentes caso vc não o use por completo e siga com outro fx como por ex o WCF. E são componentes que já "estão fácil" via NuGet, mas "tem hora" pra tentar otimizar… e se a hora chegar, ou for uma análise upfront pois já sabe volume/carga, analise, faça benchmarks e entenda o que é "bom o suficiente" para o seu caso.

[]s

2012/2/9 Ricardo <rs...@usa.com>

Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com

Bruno Fiorentino

unread,

Feb 11, 2012, 12:27:48 AM2/11/12

to dotnetar...@googlegroups.com

Vinicius, desculpe... acho que peguei pesado e escrevi muito. Você pode elaborar mais sobre o *por quê* que falta na sua perspectiva?

2012/2/9 Bruno Fiorentino <bruno.fi...@gmail.com>

Diego Caxito

unread,

Feb 12, 2012, 5:27:40 AM2/12/12

to dotnetar...@googlegroups.com

Olá Bruno,

Se em seu contexto faz sentido esse framework e se sua equipe conseguir trabalhar bem com ele, sem haver reclamações, vá em frente e use-o. Se o time começar a reclamar ou começar a ficar engessado, mude-o ou mude a estratégia, evolua!

Utilizá-lo na prática e para a entrega de projetos, com geração de VALOR REAL para sua organização é onde você terá seus melhores feedback sobre.

No final você e seu time é que tem que sentirem-se felizes e produtivos no trabalho diário com ele.

Abraço,

Diego Caxito
Analista de Sistemas

Bruno Fiorentino

unread,

Feb 12, 2012, 1:10:10 PM2/12/12

to dotnetar...@googlegroups.com

Olá Diego, concordo com suas colocações sobre buscar consenso. Quando trabalhamos solo temos liberdade para atender requisitos funcionais e não funcionais como bem entendemos para entregar valor real. Quando trabalhamos em time é preciso buscar consenso.

Comentei sobre sobre uso/reuso/abstrações e como isso é inevitável, natural e faz parte do nosso dia a dia.

Apesar de não ter explorado a brincadeira no Daniel sobre Rails assim que foi feita, mesmo pq não tenho experiência com esse fx, penso que se Rails "não é errado" só por existir o meu projeto também não seria só pelo fato de existir, merecendo uma discussão sobre suas features por pessoas *interessadas. Então apesar de pedir desculpas ao Vinicius pelo sermão sobre mining, coisas de bandeja, onde acho que exagerei e não fui cortês como somos orientados ao participar do grupo, não acho "justo" invalidar o trabalho pelo intento sem avaliar as features se não há o mínimo de interesse, vontade ou tempo.

Nesse contexto, gostaria de discutir sobre pontos específicos e componentes específicos com pessoas que considerariam o uso/reuso ou mesmo que não considerariam uso/reuso por determinados motivos ao aplicar os padrões e tecnologias mencionados (IoC/DI/AOP, ORM, Robôs, etc). Nessa linha imaginei uma discussão produtiva focada numa perspectiva arquitetural, sobre pontos positivos, negativos, etc. Algo próximo das discussões de um time para buscar consenso sobre aplicar x ou y para entregar valor, mas ainda não saímos do intento para discutir as features.

Por isso não concordo com "No final você e seu time é que tem que sentirem-se felizes e produtivos no trabalho diário com ele." se for no sentido de "vamos encerrar o assunto."

[]s

2012/2/12 Diego Caxito <diego...@gmail.com>

icalmeida

unread,

Feb 13, 2012, 12:03:29 PM2/13/12

to .Net Architects

Grande Bruno, sou seu fã!
Com certeza tem muitas soluções interessantes neste modelo, vou
precisar olhar com calma também...
Como já conheço o seu trabalho vou tomar a liberdade de fazer uma
crítica quanto ao seu post.
Você apresenta soluções para várias coisas de uma vez e talvez o
pessoal fique meio perdido e assustado, criando um pouco de rejeição
inicial.
A minha sugestão é quebrar em mais tópicos para o pessoal conseguir
assimilar melhor.
Claro que a grande sacada é combinação de tudo.
Mas indo por partes acredito que o pessoal mais fera vai poder
comentar com mais objetividade e você também vai conseguir ajudar o
pessoal mais novo!
[]s
Ivan

Bruno Fiorentino

unread,

Feb 13, 2012, 12:22:34 PM2/13/12

to dotnetar...@googlegroups.com

Fala Ivan!!

Vou seguir essa sugestão em breve. Obrigado. O Juan Lopes sugeriu algo nessa linha e estou considerando sim... mas putz, tá muito tranquilo desenvolver nessa "soluçãozona"... Depois preciso pensar com calma nesse empacotamento individual... Vou deixar de ser preguiçoso e me colocar no lugar de quem vem de fora :)

[]s

2012/2/13 icalmeida <ical...@gmail.com>

Daniel Moreira Yokoyama

unread,

Feb 13, 2012, 12:33:33 PM2/13/12

to dotnetar...@googlegroups.com

Eu discordo, Ivan...

Nenhum dos que responderam, responderam por ficarem assutados.

Ou, pra falar por mim, já que os outros não precisam da minha defesa, mesmo dividindo o framework em threads, além dele continuar tendo mais coisas do que se poderia sugerir para decisões que não deveriam ser tomadas antecipadamente, ainda iria perder o foco no framework propriamente dito (que é a combinação do todo).

Se o Bruno quebrar pra discutir cada item do stack, então será cada item do stack que será discutido e não o stack propriamente dito.

Quanto a facilitar para os mais novos, eu não sei sinceramente se isto é realmente necessário, e nem sei se ajudaria de fato. É claro que o Bruno pode decidir se vai fazer ambas... mas como os mais novos não conseguem visualizar a necessidade dos itens do stack individualmente, o que dirá então do stack inteiro. Se já é difícil explicar que WebForms é uma merda para aqueles que o acham bom por ser produtivo, imagine falar de ORM, IoC Container, AOP e tudo o mais.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

icalmeida

unread,

Feb 13, 2012, 12:58:06 PM2/13/12

to .Net Architects

Oi Daniel

Você está correto no seu comentário, acho que me expressei mal, o que
eu quis dizer basicamente é o seguinte:

Primeiro, quem chega de fora e vê várias coisas de uma vez vai ter
dificuldade de entender as motivações que o levaram a tomar cada
decisão e tende a achar que é muita coisa.
Segundo, dividir em mais tópicos não é necessáriamente é dividir em
todos os assuntos abordados, mas talvez em alguns grupos (DI/Segurança/
Produtividade, por exemplo), sempre se embasando na solução completa.

Bom esta é minha sugestão!
[]s a todos

Bruno Fiorentino

unread,

Feb 13, 2012, 12:59:06 PM2/13/12

to dotnetar...@googlegroups.com

Daniel, futuramente vou quebrar em pacotes especializados, ainda que possa continuar com um repositório "junta tudo" como referência de uso e também para facilitar o início de um projeto com arquitetura "opinionated" ainda que esta viabilize a remoção de dependências desnecessárias, como comentei sobre fazer essa "limpeza" no próprios templates de projeto do Visual Studio...

Concordo com o Ivan que fica mais fácil discutir pontos específicos assim, o que ficaria, a meu ver, mais fácil de conversar de maneira mais produtiva sobre com você e outras pessoas que consideram que o ideal é não assumir absolutamente nada, jamais. Ficaria mais fácil também conversar com quem não tem nenhuma restrição com relação a apresentação mas não está familiarizado com parte das técnicas/tecnologias -- apesar de achar que "iniciante" tem mais é que se virar no sentido de continuar buscando os pqs antes de usar qq coisa: não estou falando necessariamente de cargo xpto "junior", "pleno" e "senior", mas de correr atrás das coisas, podendo o "senior" em X ser "junior" em Y :) como todos somos nessa área.

[]s

2012/2/13 Daniel Moreira Yokoyama <moreira....@gmail.com>

Marcelo Ramos

unread,

Feb 13, 2012, 2:57:43 PM2/13/12

to dotnetar...@googlegroups.com

"é dificil explicar que WebForms é uma merda para aqueles que o acham bom por ser produtivo"

Se evitar comentários xiitas como esse pode ter algum sucesso

[]s

[]s
Marcelo Ramos

Daniel Moreira Yokoyama

unread,

Feb 13, 2012, 8:34:27 PM2/13/12

to dotnetar...@googlegroups.com

Eu até tento ajudar, mas não faço questão do sucesso.

Se ficar melhor:

"é dificil explicar que WebForms é uma merda para aqueles que o acham bom por ser produtivo e ignoram o que os mais sensatos pensam, preferindo chamá-los de xiitas"

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

edmilson hora

unread,

Feb 14, 2012, 5:14:57 AM2/14/12

to dotnetar...@googlegroups.com

Oi Daniel!

Acho que você pegou pesado nessa!!

Amigo, Webforms pode ser uma merda para você e para a sua realidade (para os projetos que você trabalha), para outros, para outras realidades, para outros tipos de de projeto Web a ferramenta (WebForms) pode atender muito bem, e ai??

Você diz que quem usa WebForms tem que ouvir o que os mais sensatos dizem. Eu acho que sensatez nesta caso é avaliar se o meu projeto requer ser desenvolvido com ASP.NET MVC ou com WebForms. A propria MS não abandonou WebForms, esta trabalhando para aprimorar, isso não significa nada para você??

ASP.NET MVC veio para suprir um gap de Web Standars que o WebForms não suporta, por outro lado, tira sim muito da produtividade para o desenvolvimento de um projeto Web, onde os requisitos de operação, sejam de um ERP, por exemplo.

Trabalho hoje, num ERP que é WEB esta em desenvolvimento a 2,5 anos (muito, muito complexo) requisitos operacionais com peculiaridades do negócio, sem nenhuma necessidade de Web Standards pois o usuário é a propria empresa, a necessidade de ser Web é o acesso remoto dos colaboradores.

Não vou me alongar.

[]´s

Edmilson

De: Daniel Moreira Yokoyama <moreira....@gmail.com>
Para: dotnetar...@googlegroups.com
Enviadas: Segunda-feira, 13 de Fevereiro de 2012 23:34
Assunto: Re: [dotnetarchitects] Re: P1 - Architectural framework for .NET based solutions

Vinícius Hana Scardazzi

unread,

Feb 14, 2012, 7:00:06 AM2/14/12

to dotnetar...@googlegroups.com

Edmilson, eu acho que você poderia rever alguns conceitos a respeito de MVC.

Me preocupa ver que ainda existe a crença de que a razão principal para a adoção do mesmo é aderência a web standards - essa aderência é casual e é bem possível não seguí-la.

O grande diferencial do MVC é como é estabelecido a separação das responsabilidades, enquanto enfraquece o acoplamento entre as partes resultantes. Isso leva inevitavelmente a software mais simples de desenvolver e manter, tanto pela organização por si só quanto por testabilidade.

Se estamos falando de "quick and dirty", scaffolding é tambem mais fácil de fazer e adaptar em MVC.

Se temos um sistema grande, caso típico de um ERP, isolar areas (coisa do ASP.NET MVC, especificamente) ajuda muito a manter a estrutura do seu código organizada tambem, coisa difícil de se alcançar de qualquer jeito.

Dá pra ter a maioria das coisas acima com WebForms, só que é muito mais trabalhoso. Não vale a pena.

E veja bem: o fato da Microsoft apoiar/melhorar algo não significa muita coisa. Ela o faz para sustentar legado e mindsets resistentes - coisa comum em qualquer grupo de qualquer área.

Não quero te convencer de nada, mas espero que isso te instigue a ver as coisas sob uma ótica diferente.

2012/2/14 edmilson hora <edmils...@yahoo.com.br>

Chander Valle

unread,

Feb 14, 2012, 7:02:44 AM2/14/12

to dotnetar...@googlegroups.com

Pow Daniel, tb acho que pegou pesado, se vc disse assim:

"é dificil explicar que WebForms é uma merda em 98% dos casos para aqueles que o acham bom por ser produtivo"

acho que ficaria melhor ;)

Leandro Mello

unread,

Feb 14, 2012, 7:12:22 AM2/14/12

to dotnetar...@googlegroups.com

Pessoal,

Sei que a discussão aqui não é webforms mas concordo com o Daniel. Webforms é ruim sim mas é muito produtivo e consolidado no mercado.
Webforms me atende até hj.

Sobre o Framework, ele nunca será uma bala de prata a não ser que você de a opção de escolha de todos os componentes. O problema é que ao fazer isso, o seu Framework se invalida pois o dev já tem essas opções independente do seu Framework. Acho ele uma boa ideia se for para ser usado pelo seu time, pois entendo que já será uma arquitetura experimentada e ira diminuir a quantidade de código escrito.

Frameworks assim são bons para o Java, que não é autosuficiente... :-P

Enviado pelo meu Windows Phone

De: edmilson hora
Enviada em: 14/02/2012 08:14
Para: dotnetar...@googlegroups.com

daniel carli

unread,

Feb 14, 2012, 7:16:30 AM2/14/12

to dotnetar...@googlegroups.com

e po, se você fala que é uma merda e não da motivos, parece que vc só ta vomitando buzzword por ai.

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

--
Daniel Carli

edmilson hora

unread,

Feb 14, 2012, 7:20:41 AM2/14/12

to dotnetar...@googlegroups.com

Respondi, só para o Daniel, mas na verdade quero que a galera avalie a discussão..

[]´s

Edmilson

----- Mensagem encaminhada -----
De: edmilson hora <edmils...@yahoo.com.br>
Para: Daniel Moreira Yokoyama <moreira....@gmail.com>
Enviadas: Terça-feira, 14 de Fevereiro de 2012 10:19

Assunto: Re: [dotnetarchitects] Re: P1 - Architectural framework for .NET based solutions

Daniel, debater com você é algo realmente em vão, já acompanho suas opiniões a muito tempo, e várias vezes concordo com seus pontos de vista, não é o caso neste tópico especifico.

Quando você fala de WebForms, parace que só tem um jeito de se trabalhar com esta ferramente, ou Seja : Wizard, Drag and Drop, SQLDataSource. Você bem sabe que não é nada disso, quem conhece e aplica padrões de arquitetura e Desing Patterns, trabalha muito bem com WebForms sim, tem controle, manutenabilidade e ganha muito em produtividade sim, sem ter que ficar enchendo a aplicação de codigo JavaScript, que isso sim, não é uma boa escolha.

Você sempre fala mau do WebForms, mas não diz o que realmente é tão pessimo assim, no máximo vai repetir o jargão:

-Não é Stateless, não é WebStandars ( o usuário tá se lixando para isso);

- ViewState carrega e suja a página ( o usuário tá se lixando para isso);

- O html é mau formado fica "feio" ( o usuário tá se lixando para isso);

- No postback recarrega a página Inteira, não é totalmente verdade (o usuario tá se lixando para isso);

E todos esses "problemas", se tratados tem solução simples.

Agora, cria um grid no MVC, com Ordenação, Paginação, e filtragem dinamica, para todas as colunas que aparecerem no ViewModel, algo que é um requisito basico do usuário no projeto que estou hoje.

Faz isso ai e sobe para algum servidor de arquivos, para a galera aprender como é facil e produtivo fazer isso no MVC.

[]´s

Edmilson

De: Daniel Moreira Yokoyama <moreira....@gmail.com>

Para: edmils...@yahoo.com.br
Enviadas: Terça-feira, 14 de Fevereiro de 2012 9:00

Assunto: Re: [dotnetarchitects] Re: P1 - Architectural framework for .NET based solutions

Em 14 de fevereiro de 2012 08:14, edmilson hora <edmils...@yahoo.com.br> escreveu:

Amigo, Webforms pode ser uma merda para você e para a sua realidade (para os projetos que você trabalha), para outros, para outras realidades, para outros tipos de de projeto Web a ferramenta (WebForms) pode atender muito bem, e ai??

WebForms não é desenvolvimento web. É uma adaptação tosca do windows forms para desenvolver web applications. É totalmente contrário a tudo o que desenvolvimento web realmente se trata. Isto não é de hoje. Não é pq o asp.net mvc existe. WebForms sempre foi uma péssima solução para desenvolver webapplications.

Sempre.

Você diz que quem usa WebForms tem que ouvir o que os mais sensatos dizem. Eu acho que sensatez nesta caso é avaliar se o meu projeto requer ser desenvolvido com ASP.NET MVC ou com WebForms. A propria MS não abandonou WebForms, esta trabalhando para aprimorar, isso não significa nada para você??

Não. Não significa nada. A MS não abandonou WebForms pq ainda tem gente que não se tocou do quanto ele é ruim e continua usando. Até lá, ela vai ser refém desse tipo de programador, que não sabe programar pra web e depende de um "windows form way of doing" pra conseguir continuar entregando projetos. Assim como os bancos não abandonaram stored procedures por que os DBA's precisam delas, mas os desenvolvedores fazem mal uso. Assim como o VB nunca morreu por que boa parte do meio milhão de desenvolvedores VB dos anos 90 nunca resolveram aprender outra linguagem.

Não, amigo. O fato de webforms ainda existir não signigica absolutamente nada pra mim, a não ser o lamentável fato de que ainda tem gente usando.

ASP.NET MVC veio para suprir um gap de Web Standars que o WebForms não suporta, por outro lado, tira sim muito da produtividade para o desenvolvimento de um projeto Web, onde os requisitos de operação, sejam de um ERP, por exemplo.

Eu discordo totalmente. Eu produzo bem melhor com MVC do que com WebForms... e ainda assim, MVC nem sempre é minha primeira escolha. Dependendo do sistema eu uso uma interface de serviços RESTFul e Backbone.js no client. Ou alguma combinação dos dois.

Isto é desenolvimento pra web. Stateless pra dizer o mínimo.

Trabalho hoje, num ERP que é WEB esta em desenvolvimento a 2,5 anos (muito, muito complexo) requisitos operacionais com peculiaridades do negócio, sem nenhuma necessidade de Web Standards pois o usuário é a propria empresa, a necessidade de ser Web é o acesso remoto dos colaboradores.

Isso não significa que WebForms é a melhor alternativa. Na verdade é justamente nestes cenários que WebForms é a pior escolha, ou por ser medonho e terrível para dar manutenção quando na sua forma mais produtiva, ou por que é muito mais trabalhoso pra não ser medonho e terrível, levando muito mais tempo do que precisaria pra fazer o que se precisa fazer.

Péssima escolha. Espero que as outras escolhas (persistência, caching, mensageria) tenham sido melhores.

Ainda bem que isso não é problema meu. E ainda bem que eu não trabalho neste mesmo projeto. O que te dá o direito de me achar um otário por pensar assim, e fazer como bem quiser e entender. Sinceramente eu não ligo. Até gosto dos apelidos que me dão.

Daniel Moreira Yokoyama

unread,

Feb 14, 2012, 7:22:54 AM2/14/12

to dotnetar...@googlegroups.com

@Daniel

Eu como buzzwords no café da manhã.

@Chander

"é dificil explicar que WebForms é uma merda em 101% dos casos para aqueles que o acham bom por ser produtivo"

De qualquer forma, o ponto não era focar no WebForms x MVC. Foi só lançar isso no ar e a thread ficou movimentada do jeito que o Bruno queria, mas infelizmente não tá sendo pra discutir o que ele propôs... shame.

De repente todo mundo tem tempo pra contra-argumentar.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

edmilson hora

unread,

Feb 14, 2012, 7:28:20 AM2/14/12

to dotnetar...@googlegroups.com

Vinicius,

concordo com o que você colocou, principalmente quando você diz que pode ser tudo isso feito em WebForms, que é mais trabalhoso, não estou convencido!

Se você sabe e aplica bem os padrões, a interface com o usuário vira detalhe, pode ser qualquer interface.

[]´s

Edmilson

De: Vinícius Hana Scardazzi <vins...@gmail.com>
Para: dotnetar...@googlegroups.com
Enviadas: Terça-feira, 14 de Fevereiro de 2012 10:00

Juan Lopes

unread,

Feb 14, 2012, 9:01:22 AM2/14/12

to dotnetar...@googlegroups.com

Por "autosuficiente" você quer dizer "não tem uma empresa por trás regulando o que você deve ou não usar"?

Se for assim, prefiro o Java. Mas continuo detestando frameworks caseiros.

2012/2/14 Leandro Mello <leand...@gmail.com>

Winston Pacheco Junior

unread,

Feb 14, 2012, 10:15:35 AM2/14/12

to dotnetar...@googlegroups.com

+1

leandro9119

unread,

Feb 14, 2012, 10:49:37 AM2/14/12

to dotnetar...@googlegroups.com

Juan,

É só uma zoação com a imensidade de frameworks para o Java... =]

Eu não conheço Java o suficiente para afirmar que ele é dependente de frameworks.

Bruno Fiorentino

unread,

Feb 14, 2012, 11:03:53 AM2/14/12

to dotnetar...@googlegroups.com

Problema mesmo para mim é escrever "1000 linhas" de regras de negócio no evento "Load" ou "Click", bem como escrever actions de "1000 linhas"... até considero o MVC como "default" (não penso muito sobre) para a maioria dos casos, mas ao aceitar trabalhar num legado/brownfield e "critério das linhas" prevalece.

Eu desenvolvo tendo em mente que o próximo a por as mãos no código pode ser um "psicopata entediado que tem meus contatos e sabe quem eu amo". Ou talvez apenas eu -- "não fui diagnosticado" -- 6 meses depois -- melhor por aspas pra deixar claro a brincadeira, embora a dúvida poderia ajudar a acabar tanto nessas discussões intermináveis sobre o intento como nessa de WebForms Vs. MVC e manter o foco :P

Pessoal, desencana dessa briga aí, não dá em nada. Hoje temos WebForms, "MVC", Tiny Web Fxs, Evented I/O: temos *opções. Eu acho isso muito importante. Por isso não entendo o ponto em questionar tanto esse projeto pelo intento -- considerando que é pequeno (LoC), entre outros motivos já abordados extensivamente -- nem ponto em brigar por WebForms Vs. MVC.

Além de ter alguma diversão e expor parte do meu trabalho estou contribuindo à minha maneira -- já criei uns 2 blogs e nunca consegui sair do hello world -- com mais *opções... até pq tenho feito bastante uso do que foi exposto por outros grupos/pessoas e sinto vontade de retribuir.

Tenho a impressão que realmente falta um pouco disso no ecossistema .NET, se comparado à outras plataformas. E já "tá virando moda" falar sobre "Pq estou deixando .NET" Brasil a fora, então daqui a pouco "vira moda" aqui tb... apesar de achar a maioria dos depoimentos exagerados/chorões, eles tem alguns pontos válidos, em parte, sobre "menos inovação", "inovação só chega depois", "open source mais ou menos", sobre poucos projetos e "discussões ruins" -- isso gera uma certa "inveja" das outras plataformas, tanto em desenvolvedores como outros papeis. Eu sei eu sei sobre o programador poliglota -- e agora o Martin Fowler lançou "persistência poliglota" também -- mas acho que faz parte focar (depth) em determinada plataforma.

Apesar de inevitavelmente ficar com algum sentimento de débito quando uso tais bibliotecas, veja, não sou tão bonzinho/idealista/altruísta assim, tenho interesses comerciai$ também -- não trabalho para uma ong e nem sou adepto do Richard Stallman. Eu investi bastante tempo em .NET -- e quero continuar colhendo fruto$ --, gosto das linguagens e da plataforma, que comporta quase qualquer linguagem/paradigma, o que permite interoperar e se "acomodar" no mesmo runtime -- o que remete a uma grande diversidade de opiniões, modos de usar/fazer, backgrounds, etc. Gostaria de ver a MS evoluindo e criando "apêndices" de acordo com os seus interesses e o Mono crescendo e ganhando importância também, oferecendo interoperabilidade (até certo ponto) e ofertas especiais (mobile, games, etc.) somado à um ecossistema cada vez mais *rico para *ambos, pois até onde não são muitas as libs que não suportam os dois.

Se a gente pensar em tudo isso, essas discussões ficam pequenas… é melhor cada um contribuir a sua maneira no que gosta/prefere/usa/acredita e tentar entender os pqs dos outros antes de argumentar (pesado, tipo arguing em inglês) e principalmente não entrar em discussões "intermináveis" e/ou que excluam as pessoas -- não quero sair apontando o dedo, já fiz isso e estou sujeito, mas tento me policiar... assim o bolo cresce para todos e a plataforma que em que investimos continuará competitiva, não vai virar o "patinho feio" das plataformas.

Já li/ouvi (passei por um tb) sobre vários casos onde .Net é excluído pela "cultura" e não pela qualidade -- para quem abstrai, quer escolher logo e ir pensar em outras coisas, é uma coisa só. Novamente: isso não me agrada como desenvolvedor nem comercialmente.

Geralmente as pessoas que avaliam/decidem/põe grana ou são "gente de negócio" ou gente com background em TI/desenvolvimento mas hoje "só gerencia", já perderam um pouco o contato que nós temos -- sem querer iniciar mais uma discussão: "carreira y ou não". As abstrações que usam para tomar tais decisões não lhes permitem fazer uma análise criteriosa das discussões do grupo, só vão ver a quantidade, o tamanho, os loops, a falta de foco e possivelmente escolher outra plataforma. Não que eu queira aniquilar as outras plataformas ou entrar em discussões profundas sobre market share, mas acho que isso não é de interesse de ninguém especializado nessa plataforma, conhecendo outras ou não.

[]s

2012/2/14 edmilson hora <edmils...@yahoo.com.br>

Bruno Fiorentino

unread,

Feb 14, 2012, 12:42:20 PM2/14/12

to dotnetar...@googlegroups.com

Quais opções?

[]s

2012/2/14 Leandro Mello <leand...@gmail.com>

Winston Pacheco Junior

unread,

Feb 14, 2012, 12:46:22 PM2/14/12

to dotnetar...@googlegroups.com

Sobre Frameworks para Java ou .Net?

Bruno Fiorentino

unread,

Feb 14, 2012, 12:53:40 PM2/14/12

to dotnetar...@googlegroups.com

Não.

"O problema é que ao fazer isso, o seu Framework se invalida pois o dev já tem essas opções independente do seu Framework."

Alternativas que "o dev tem" ao que publiquei.

[]s

2012/2/14 Winston Pacheco Junior <winston...@gmail.com>

Winston Pacheco Junior

unread,

Feb 14, 2012, 1:05:48 PM2/14/12

to dotnetar...@googlegroups.com

spring.net

leandro9119

unread,

Feb 14, 2012, 1:01:32 PM2/14/12

to dotnetar...@googlegroups.com

Eu posso hoje implementar no meu projeto Repository, DI, Testes e etc sem a necessidade de um "framework de frameworks".

Se o stack dele é engessado, me privará do poder de criação. Se o stack dele for flexível, vai se igualar as opções que já tenho hoje. No máximo dando uns 10% de produtividade.

Agora, como já disse, se ele adotar o stack dele como padrão de projetos para o time dele, legal. Acredito que o ganho de produtividade será maior.

Há uns meses atrás fiz um projeto semelhante de automatização de desenvolvimento e diminuimos 60% do esforço para desenvolver uma funcionalidade. Isso serviu pois é um sistema corporativo e queriamos definir padrões para os devs, logo facilitou a nossa padronização. Agora, se eu pego a aplicação de que desenvolvi e distribuo no mercado, será rejeitada pela maioria pois talvez não se aplicará ao contexto das pessoas.

Bruno Fiorentino

unread,

Feb 14, 2012, 1:09:10 PM2/14/12

to dotnetar...@googlegroups.com

Nada contra o Spring, mas esse realmente é grande :)

Eu só postei meia dúzia de bibliotecas (umas colas outras não) sub uma mesmas solution...

Já até reduzi o número ontem!

Bruno Fiorentino

unread,

Feb 14, 2012, 1:24:20 PM2/14/12

to dotnetar...@googlegroups.com

Entendo o que diz, mas o que é relativo... depende. Não vejo uma regra geral como coloca.

Eu desenvolvi as coisas do zero, com base na minha experiência anterior, da maneira mais sucinta "possível" (falando dos componentes isoladamente) no intuito de não refazer mais nada do zero pela enésima vez qdo precisar de algo parecido novamente -- considerando que tendo a usar bastante os padrões/ferramentas em questão. Fiz também para ter algo adiantado se uma adaptação/extensão/simplificação resolver o problema a mão.

Outro ponto é querer ter algo já adiantado quando empresa/equipe/pessoas priorizar ferramentas MS (EF, Unity, etc.).

Esse tipo de arquitetura IMO é bastante útil e já está "batido", acho muito chato ficar montando "toda hora": é mais fácil pegar "o todo" e excluir o que não quer/precisa e boa.

Agora, se vou criar um projeto bem diferente... desencana... talvez um ou outro componente seja útil (gerador de hosts para robôs e parsing de app setttings por exemplo).

[]s

2012/2/14 leandro9119 <leand...@gmail.com>

Winston Pacheco Junior

unread,

Feb 14, 2012, 1:36:02 PM2/14/12

to dotnetar...@googlegroups.com

Você não perguntou isso... Perguntou sobre um framework que faz o que o P1... Ele faz e faz MAIS, MUITO MAIS...

Opinião pessoal: "Não gosto", mas vejo muitas pessoas felizes usando, tem uma comunidade forte por trás... Enfim... Você pode usar módulos dele também...

É um port de um projeto grandão em Java também, de ponta a ponta, desde componentes web até persistência... Maduro.

Bruno Fiorentino

unread,

Feb 14, 2012, 1:41:01 PM2/14/12

to dotnetar...@googlegroups.com

Entendi...

É que vejo o P1 como algo tão pequeno que até perde a característica de "caixa preta". O que seria uma vantagem comparado ao Spring entre outras alternativas maiores e mesmo mais maduras ao iniciar um projeto.

Thiago C. Santos

unread,

Feb 14, 2012, 2:45:20 PM2/14/12

to dotnetar...@googlegroups.com

Daniel, você diz que WebForms é uma merda sendo que ele foi utilizado por muito tempo com um grande SUCESSO e sendo que eu e muitas pessoas aqui no grupo usaram, usam ou vão usar caso NECESSÁRIO (seja la qual for o motivo mesmo que possa ser improvável), o WebForms não é uma MERDA como você diz, ele simplesmente não é a melhor opção no momento por existirem melhores opções a serem adotadas (Assim como algum dia o Asp.Net MVC vai ser trocado por algo melhor).

Quando você disse sobre as pessoas não escutarem pessoas mais sensatas você estava referindo a você mesmo?

obs: Acho estranho a comunidade toda do .Net sentar o pau em uma tecnologia que usou por muito tempo e que a defendia com unhas e dentes contra outras soluções como as do Java por exemplo (Que são muito similares a do Asp.Net MVC)...

Att,

Thiago C. Santos

2012/2/14 Bruno Fiorentino <bruno.fi...@gmail.com>

Juan Lopes

unread,

Feb 14, 2012, 2:48:33 PM2/14/12

to dotnetar...@googlegroups.com

Defina "comunidade toda do .Net". A mesma galera que defendia WebForms no passado é a que defende TFS, Sharepoint e WPF hoje. E se isso é a "comunidade toda do .Net", me exclua dessa estatística.

2012/2/14 Thiago C. Santos <thiago.c...@gmail.com>

daniel carli

unread,

Feb 14, 2012, 2:51:01 PM2/14/12

to dotnetar...@googlegroups.com

@Thiago C. Santos

Daniel Carli

Rodrigo Vidal

unread,

Feb 14, 2012, 2:52:25 PM2/14/12

to dotnetar...@googlegroups.com

Por favor, me exclua também :)

Abraço,

Rodrigo Vidal

www.rodrigovidal.net

daniel carli

unread,

Feb 14, 2012, 2:52:51 PM2/14/12

to dotnetar...@googlegroups.com

antes do asp.net mvc, existia o alt.net, então a galera que senta o pau no webforms hoje, sentou o pau no webforms no passado.

o grande problema da galera que vê o WebForms como um puta sucesso é que só sabem olhar para os rebentos da MS, nunca conseguem olhar um palmo para fora.

o que eu quero dizer é: foi, é e sempre será uma merda.

Em 14 de fevereiro de 2012 16:51, daniel carli <dansa...@gmail.com> escreveu:

--
Daniel Carli

daniel carli

unread,

Feb 14, 2012, 2:54:17 PM2/14/12

to dotnetar...@googlegroups.com

o que eu quis dizer com alt.net são outras opções, como monorails, fubu e afins

--
Daniel Carli

http://en.wikipedia.org/wiki/Front_Controller_pattern

Vinícius Hana Scardazzi

unread,

Feb 14, 2012, 2:55:27 PM2/14/12

to dotnetar...@googlegroups.com

Pronto, é isso mesmo. Pode me excluir tambem.

E como uma nota paralela, me parece que alguns não entendem que MVC é um padrão bem antigo, datado de 1978. O que estamos chamando de ASP.NET MVC é uma implementação do padrão. Com isso, sim, é bem possível criticar o WebForms desde sua concepção.

2012/2/14 Juan Lopes <m...@juanlopes.net>

Bruno Fiorentino

unread,

Feb 14, 2012, 3:04:09 PM2/14/12

to dotnetar...@googlegroups.com

Apesar do nome dado, para simplificar, concordo que é uma implementação do padrão FrontController:

http://martinfowler.com/eaaCatalog/frontController.html

http://mvc.fubu-project.org/

MVC mesmo como o de 1978 acho que pode ser aplicado "lá em cima", no JS... Algo que preciso entender melhor, IMO "não ajuda muito" fazer "MVC" em baixo e escrever "event-driven" no browser quando a aplicação tem muito AJAX ou característica de Single Page Application.

[]s

2012/2/14 Vinícius Hana Scardazzi <vins...@gmail.com>

Daniel Moreira Yokoyama

unread,

Feb 14, 2012, 8:41:28 PM2/14/12

to dotnetar...@googlegroups.com

Me exclua da estatística também... nunca gostei do webforms a não ser pelo curto período de transição entre vb6 e desenvolvedor web.

E sim, eu me referia a mim mesmo, inclusive... e muitos outros que concordam comigo (talvez não no mesmo gênero, número e grau, já que só eu estou sendo taxado de xiita fanático).

WebForms é Windows Forms pra web. Isso não é a minha opinião... é o que ele é.

Quando vc clica num botão não existe intention revealing. existe um evento de click que não passa de um clique qualquer, sem semântica. Não é minha opinião, é o que é.

Nem mesmo quando eu era estúpido demais pra saber que haviam outras soluções como o monorails, nem mesmo aí, eu gostava de webforms, quando era a única merda que me ofereciam pra usar.

Mesmo quando aprendi RSP, DI... mesmo quando descobri que meu código era um lixo e passei a me preocupar com questões de organização, mesmo aí, eu detestava webforms, e passava a odiá-lo ainda mais pq eu só queria postar a porcaria do conteúdo do campo de pesquisa... mas o desgraçado criava um request com todo o estado da minha página.

Mesmo quando aprendi a desligar o viewstate, e descobri que o viewstate continuava lá... Ou quando surgiu o Atlas, mais conhecido como ajax.net, e vi que o update panel só aumenta a cada update. Mesmo quando descobri que se quisesse usar ajax de verdade, tinha que ser num nível muito mais cru que o update panel.

Até que chegou o dia que minhas páginas não tinham nada além do load, e os métodos eram webservices acessíveis por script. Mesmo ali, eu já morria de ódio do webforms que eu já nem gostava mais de usar.

Veja, WebForms sempre foi uma merda. Nunca foi bom. E isso não é exatamente a minha opinião. É o que ele é. Windows Forms pra web.

PS: um dia, nos tempos do sql 6.5, eu gostava de stored procedures. saca?

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

edmilson hora

unread,

Feb 15, 2012, 4:13:36 AM2/15/12

to dotnetar...@googlegroups.com

"WebForms é Windows Forms pra web. Isso não é a minha opinião... é o que ele é."

É isso mesmo, você tem toda razão, ele é isso mesmo, e serviu ao proposito principal, diminuir o impacto da sua transição entre VB6 e Web.

"Quando vc clica num botão não existe intention revealing. existe um evento de click que não passa de um clique qualquer, sem semântica. Não é minha opinião, é o que é."

Mude o nome do evento, isso é tão simples!!

"e passava a odiá-lo ainda mais pq eu só queria postar a porcaria do conteúdo do campo de pesquisa... "

Isso não tem impacto relevente para uma aplicação Web, mesmo assim se vc utilizasse o Ajax, diminuiria o problema.

"Até que chegou o dia que minhas páginas não tinham nada além do load, e os métodos eram webservices acessíveis por script. Mesmo ali, eu já morria de ódio do webforms que eu já nem gostava mais de usar."

Bom, se vc tinha realmante que fazer essas manobras todas para fazer suas aplicações funcionarem a contento usando WebForms, tá exlicado porque você odeia tanto, eu também odiaria fazer isso dessa maneira.

De: Daniel Moreira Yokoyama <moreira....@gmail.com>
Para: dotnetar...@googlegroups.com

Enviadas: Terça-feira, 14 de Fevereiro de 2012 23:41

Thiago C. Santos

unread,

Feb 15, 2012, 5:56:07 AM2/15/12

to dotnetar...@googlegroups.com

Podem aparecer quantos quiserem aqui querendo se excluir desta generalização da "comunidade toda do .Net", porem é fato que a grande maioria gostava dele.

Vinícius, concordo com você neste ponto (Assim como eu citei que Java bem antes do Asp.Net MVC ja possui-a um framework MVC para web e a " comunidade do .Net" defendia o WebForms), muito antes do Asp.Net MVC podia sim falar que o WebForms não era a solução IDEAL mas mesmo assim ele foi um SUCESSO ao que se propôs.

antes do asp.net mvc, existia o alt.net, então a galera que senta o pau no webforms hoje, sentou o pau no webforms no passado.

Daniel Carli, você esta generalizando assim como eu, não concordo com você por que a comunidade do .Net tende a usar apenas as soluções oferecidas pela Microsoft (Mesmo que eu não concorde com isso, eu também me excluo dessa), então muita mas MUITA gente foi direto do WebForms para o Asp.Net MVC.

Daniel Moreira, os "defeitos" do WebForms acho que já esta mais do que claro para todo mundo, o problema é quando uma pessoa coloca defeito na tecnologia por conta de algo que não esta sabendo usar (Como o viewstate que você cita, ele te dava tanta dor de cabeça por que você não estava sabendo usar).

Att,

Thiago C. Santos

2012/2/15 edmilson hora <edmils...@yahoo.com.br>

Daniel Moreira Yokoyama

unread,

Feb 15, 2012, 6:11:41 AM2/15/12

to dotnetar...@googlegroups.com

Você tá tão afim de continuar discutindo, que ignora muito do que eu digo.

Mudar o nome do evento não o torna intention revealing. Você recebe o disparo do evento e precisa garimpar seus dados pela view pra fazer o que é preciso. E o que você tem são, na melhor das hipóteses, textboxes, dropdownlists, checkbox, etc.

Então ao invés de simplesmente receber um valor de intenção semântica, como um boolean "Active" (só pra exemplificar), você além de não receber nada, ainda tem que sacar que existe um chkActive, e pegar a propriedade checked.

Caraca, não tem condição alguma de eu fazer um "AdicionarAoCarrinho(ItemDeCompra item)" no WebForms. E você realmente quer me convencer que é melhor um "btnAdicionarAoCarrinho_Click(EventArgs e, object handler)"?

Dizer que postar todo o estado da página pra pegar um campo de pesquisa (isto mesmo, txtPesquisa e um btnPesquisar, posta todos os dados de formulário presente na view) é irrelevante para uma aplicação Web, meu amigo, você não é um desenvolvedor web. E me desculpe a franqueza, mas isto explica muito do por que você insiste tanto em dizer que o WebForms te faz feliz.

By the way, eu usei Ajax... e muito. Esta é a parte que você fingiu que eu não escrevi. Por que eu falei a respeito disto, e do maravilhoso milagre que o UpdatePanel faz se vc desconsiderar toda a merda que ele faz por baixo dos panos. Mas, como eu disse também, vc consegue usar o Ajax como uma api que publica os métodos Ajax para serem usados via javascript, que também não é nada muito bonito... mas funciona. Só que aí já se foi a tal produtividade.

Estas manobras que eu fiz pra fazer algo que preste usando WebForms (que na verdade eram manobras para não usá-lo) se mostraram muito eficazes no que diz respeito a aumentar a escalabilidade. Eu reduzia o gargalo que era culpa do webforms, e todo o resto já tava bem feito. Se vc tiver tão disposto assim pra continuar dizendo que era eu que me atrapalhava com o mal uso do webforms (junto com todos os demais que também o acham ruim) fique a vontade pra esclarecer como são as suas tais "boas práticas" que deixam sua aplicação tão bem feita.

Senão, fique a vontade também pra não insistir na discussão com os mesmos argumentos... até aqui eu falei de n problemas do webforms e vc não me deu nenhum exemplo de como resolvê-los mantendo a tal "boa prática" e a produtividade que vc tanto ama (e julga não conseguir com mvc).

Se não tiver nada novo pra falar, faça um grande favor pra lista, e não fale nada. Se houver algo que ainda valha a pena ser dito, eu responderei só no fim do dia. (até pq, isto é um puta desperdício do meu precioso tempo tentando te mostrar a luz).

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Daniel Moreira Yokoyama

unread,

Feb 15, 2012, 6:12:32 AM2/15/12

to dotnetar...@googlegroups.com

Thiago, eu não uso viewstate... quem usa é o WebForms (obs: mesmo quando vc desativa ele. Fato.)

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Thiago C. Santos

unread,

Feb 15, 2012, 6:14:01 AM2/15/12

to dotnetar...@googlegroups.com

Daniel Moreira, então ai esta o seu erro, não esta usando certo o WebForms.

Att,

Thiago C. Santos

2012/2/15 Daniel Moreira Yokoyama <moreira....@gmail.com>

Daniel Moreira Yokoyama

unread,

Feb 15, 2012, 6:19:02 AM2/15/12

to dotnetar...@googlegroups.com

Certo...

Como eu sei que não estou usando ele errado tb (:S) e você não se deu o trabalho de explicar qual o erro (pq não há) eu vou fingir que não li nada e voltar a trabalhar.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)

Stay Sharp!

Marcus Alexandre Silva

unread,

Feb 15, 2012, 6:32:56 AM2/15/12

to dotnetar...@googlegroups.com

Isto é arquitetura? Discutir qual a melhor tecnologia sem ter um contexto de produto como base? Menos pessoal... Ano que vem estaremos falando o quão Mvc é ruim e que XXX mudou o mundo... Menos...

Daniel Moreira Yokoyama

unread,

Feb 15, 2012, 7:13:00 AM2/15/12

to dotnetar...@googlegroups.com

Concordo.

O interessante é que quando o assunto é arquitetura de fato, ninguém parece se interessar.

Atenciosamente,

Daniel Moreira Yokoyama.

@dmyoko

Blogs:

Getting Sharper (C#, Arquitetura de Software e outras coisas mais)
http://gettingsharper.wordpress.com/

Eis o Cristo... e jaz o Cristão (Cristianismo sem Religiosidade)