.NET,C#, CLR,CLI,Boas práticas,Arquitetura,Agile
asp.NET
Não existe nada mais facil que o novo ASP.NET MVCThere isn’t anything easier than the new ASP.NET MVC
0909 days
Olá pessoal,
Eu estou brincando no asp.net mvc desde o preview 6 dele, como você pode ver há muitas pessoas tentando melhorar a qualidade do software através do MVC. Eu posso dizer que minha experiência com esta tecnologia está sendo legal.
A questão desse post, é que como qualquer nova tecnologia há muitos iniciantes tentando, com isso essas pessoas não tem cuidado sobre padrões e melhores práticas, assim provavelmente elas estão fazendo o mesmo que elas fariam com webforms.
O engano mais comum é causado pela incompreensão dos conceitos básicos do MVC, onde pessoas ainda entendem que o MVC é como:
M – Significa o lugar onde você coloca seus modelos, dados ou coisas relacionadas;
V – Seu código html, a interface com o usuário;
C – Todos os códigos que fazem a aplicação rodar.
Eu estava tendo uma conversa com um meu e ele disse que coloca a regra de negócio dele dentro do controller. Eu sugeri a ele colocar o código em um outro projeto e usar o controller apenas para gerenciar requisições e questões relacionadas. Ele disse que faria isso mas onde iria colocar os dados dele? Eu acho que em outro projeto também. Neste modo ele acaba apenas adicionando referência para o negócio e o projeto de dados dentro do projeto web dele.
Todo esse texto foi apenas um exemplo. Eu estou preocupado sobre como as pessoas tendem a usar o MVC, em uma mão há muitas pessoas gastando tempo sugerindo melhores práticas mas na outra há pessoas que não se importam com isso.
Eu li em um post de alguém que disse:
“Não é suficiente construir aplicações sobre os padrões, você ainda poderá fazê-las pobres e fracas.”
Ps.: Eu sei que eu posso melhorar meus projetos MVC. Eu também sou uma dessas pessoas descritas
Olá pessoal,
Eu estou brincando no asp.net mvc desde o preview 6 dele, como você pode ver há muitas pessoas tentando melhorar a qualidade do software através do MVC. Eu posso dizer que minha experiência com esta tecnologia está sendo legal.
A questão desse post, é que como qualquer nova tecnologia há muitos iniciantes tentando, com isso essas pessoas não tem cuidado sobre padrões e melhores práticas, assim provavelmente elas estão fazendo o mesmo que elas fariam com webforms.
O engano mais comum é causado pela incompreensão dos conceitos básicos do MVC, onde pessoas ainda entendem que o MVC é como:
M – Significa o lugar onde você coloca seus modelos, dados ou coisas relacionadas;
V – Seu código html, a interface com o usuário;
C – Todos os códigos que fazem a aplicação rodar.
Eu estava tendo uma conversa com um meu e ele disse que coloca a regra de negócio dele dentro do controller. Eu sugeri a ele colocar o código em um outro projeto e usar o controller apenas para gerenciar requisições e questões relacionadas. Ele disse que faria isso mas onde iria colocar os dados dele? Eu acho que em outro projeto também. Neste modo ele acaba apenas adicionando referência para o negócio e o projeto de dados dentro do projeto web dele.
Todo esse texto foi apenas um exemplo. Eu estou preocupado sobre como as pessoas tendem a usar o MVC, em uma mão há muitas pessoas gastando tempo sugerindo melhores práticas mas na outra há pessoas que não se importam com isso.
Eu li em um post de alguém que disse:
“Não é suficiente construir aplicações sobre os padrões, você ainda poderá fazê-las pobres e fracas.”
Ps.: Eu sei que eu posso melhorar meus projetos MVC. Eu também sou uma dessas pessoas descritas
Quem deve validar? a função que chama ou a função chamada?
0Fala galera, desta vez vamos falar sobre a responsabilidade de validação dos dados. Quem deve validar, a função que está sendo chamada ou a função que chama?Acho que este é um assunto defendido de diversas maneiras por nós, programadores. Eu não fazia a mínima idéia antes de conhecer o design por contrato(DBC). No DBC contratos são realizados e todas as partes envolvidas devem respeitar o contrato. Se você ainda não conhece o DBC pode olhar um pouco aqui e aqui. Basicamente o contrato é estabelecido indicando o que a função precisa receber(validade dos parâmetros) e o que ela vai retornar quando recebe os parâmetros necessários. Os contratos podem ser feitos com ferramentas como o CodeContracts ou até com comentários,Vamos olhar um exemplo usando comentários
1: public class Calculadora
2: {
3:
4: /// <summary>
5: /// Realiza a divisão entre dois numeros
6: /// </summary>
7: /// <param name="dividendo">Pode ser qualquer valor</param>
8: /// <param name="divisor">Pode ser qualquer valor exceto 0</param>
9: /// <returns></returns>
10: public static Decimal Dividir(Decimal dividendo, Decimal divisor)
11: {
12: return dividendo / divisor;
13: }
14: }
Bem, na pior das hipóteses o desenvolvedor sabe que a validação deve ser feita antes de chamar a função apresentada, além disso sabe que se passar os parâmetros corretos vai obter uma resposta valida. As coisas ficam mais legais quando você está usando ferramentas como o CodeContracts.
Além da notificação ao usuário da função fica relativamente mais fácil de escrever testes para validar o contrato da função, temos em mente quais contratos devem ser respeitados e quais não devem. Uns exemplos de testes contra o contrato.
1: [TestClass]
2: public class CalculadoraTeste
3: {
4:
5: [ExpectedException(typeof(DivideByZeroException))]
6: [TestMethod]
7: public void TesteDividir_DividindoPorZero()
8: {
9: Calculadora.Dividir(10, 0);
10: }
11:
12: [TestMethod]
13: public void TesteDividir_ValorMaximo()
14: {
15: Assert.AreEqual(1, Calculadora.Dividir(Decimal.MaxValue, Decimal.MaxValue));
16: }
17: public void TesteDividir_parametrosSimples()
18: {
19: Assert.AreEqual(10, Calculadora.Dividir(100, 10));
20:
21: }
22:
23: }
Bem, com o DBC aprendi este modelo de desenvolvimento onde na maioria das vezes o cliente deve fazer a validação antes da chamada do método. Os principais benefícios desta abordagem são relacionados à separação de responsabilidades. Quando o cliente valida os dados é possível criar por exemplo uma camada Fachada responsável pelas validações e isolar o Núcleo do sistema que agora não se preocupa mais com códigos de validação. O legal do facade é quando você ainda consegue aproveitar ele em diversos ambientes diferentes, por exemplo trabalho em um projeto onde o Facade é utilizado via Ajax, assim a validação cliente e servidor não fica duplicada.
Outro beneficio legal é a maior facilidade de propagar erro e invalidade dos dados, afinal de contas você vai estar uma camada mais próxima do cliente, não precisa ficar propagando erros por N camadas.
Concluindo, O DBC me ensinou uma maneira legal de validar os dados. Nos projetos em que trabalho gosto da idéia do projeto fachada apesar de ter que escrever mais código ficou feliz em eliminar a duplicidade de validações.
Adicional: você ainda pode gerar testes beaseados em contratos, olhe esta ferramenta.
Integração Locaweb Gateway de pagamento versão 0.5Integração Locaweb Gateway de pagamento version 0.5
0953 days
Fala Galera,
hoje eu liberei o código da versão 0.5 da API de integração com o gateway de pagamento da locaweb. A versão 0.5 contém o código responsável pelo processo de captura do VISAVBV e uma documentação sobre todo o funcionamento do módulo VISAVBV da API. Estou retomando o desenvolvimento aos poucos para melhorar o código e produzir a documentação que é a prioridade agora. Bem é isso, abaixo estão os links
Locaweb gatewayHello Folks,
Today I published the version 0.5 of API de integração com o gateway de pagamento da locaweb. The version 0.5 contains a lot of documentation and the code that executes the final part of VISAVBV sale process. I’m working to improve the API code and produce some documentation. You can see the links below
A way to use facades
01059 days
Hello folks, Today in the morning I was reading my email when I saw an interesting post at dotnetarchitects. This post is a discussion about facades and its implementation. A lot of people gave their tips, I also recommend you have a look, I gave my tip too. My tip was based in my experience when using facades.
I’m working in a project called comperio, in this project I have been trying to be a junior architect. We(dev Team) thought that would be nice if we had a layer that could do all validations and if these validations were ok this layer could call the layer that knows how to process the operation.We had decided to use a Facade layer to do these validations, but this facade layer were an server-side layer and we thought, should we do the same code in client side to improve the UX ? after some discussion we decided to use the facade layer to do the validation in both. So we write an action that calls the validate method in facade and it worked fine.
A facade was used because we think that the business logic layer should work as system’s core. Thus any error that could be avoided should avoid before enter in the system’s core. If you look our architecture you can see that the UI project has a reference to Facade project and nothing more. So, every layer or application that wants to use our system’s core must call our facade. The other reason to do it was that we want provide an API, an this API cant use core resources without some validations.
This approach is a simple way to implement validation, if you agree the idea that validation should be done in client and server side. Other cool tip I read was the use of keys in the assembly so we can ensure that the UI project is Using the Facade project.
Validando campo hora
01291 days
Fala galera, estava aqui pensando em uma maneira simples e eficiente de validar um campo de hora(AM/PM) em uma das telas do sistema. Pra ser sincero procurei primeiro em inglês..Estava perdendo tempo, tive a idéia de usar uma expressão regular para validar o campo hora.
Expressão: ^([0-1][0-9]|[2][0-3]):([0-5][0-9])$
Validador do asp.NET configurado:
É isso galera.. Até mais…
Trabalhando com recursão em controles criados pelo usuário
01384 days
Fala Galera, Agora mesmo estávamos discutindo aqui na empresa como usar recursão entre controles criados pelo usuário(Asp.Net – UserControl). O problema é o seguinte, temos um controle chamado profile, este controle possui vários campos de um simples cadastro(nome,endereço,E-mail,telefone e etc..).Temos a necessidade de colocar um controle de profile dentro de outro, é o caso que uma pessoa possui um conjugue. Então estávamos pensando como “chamar” um controle dentro do outro sem causar um loop infinito.Então chegamos a seguinte conclusão: No nosso controle profile criaremos uma propriedade HasConjugue(que é false como default) e criaremos um atributo para esta propriedade permitindo assim que ela seja setada como true quando necessário causando assim uma recursão. Então o funcionamento do controle ficou da seguinte maneira: no load do controle verificamos uma propriedade(hasconjugue) e se essa propriedade for verdadeira então carregamos outro controle, lembrando que como default é false nós só carregamos outro controle se na configuração de uso do profile(chamado) colocarmos a propriedade para verdadeiro.Sendo a propriedade verdadeira no primeiro load do controle a propriedade sera true então carregaremos um novo controle, Entretanto no novo controle carregado a propriedade estará false como default então um novo controle não será carregado. É isso galera, quem não entendeu pode entrar em contato ok? Até mais… Boa semana