Left fold

The Single Responsability Principle is one of the five S.O.L.I.D. principles in which i base my everyday programming. It tells us how a method or class should have only one responsability. Not a long time ago i was designing a reporting service with my colleague Nuno for an application module we were redoing and we had a method that was responsible for being both the factory method of a popup view and showing it to the user. You can see where this is going now... I figured out it would not be a that bad violation of the principle, so we moved on with this design. The method was called something like "ShowPrintPopup" and it took an IReport as an argument. All this was fine, but then we got to a point where we needed to have a permissions system to say if the user was able to export the report to Excel, Word, PDF, etc... The problem was the print popup would need to know beforehand if it would allow the user to export the report or not, so that it could show it's UI a

Uma das limitações que o EF ainda tem é o seu suporte para múltiplas bases de dados. A opção simplesmente não é suportada à partida, apesar de atrair muitos votos no UserVoice . Antes de mais, quero dar crédito aos autores da ideia original. Esta ideia não  foi minha. Eu fiz download do script original, utilizei-o e depois reescrevi-o quase  completamente para lidar com alguns casos adicionais. Eu adoro Linq, por isso aproveitei para utilizar bastante na nova versão. O script original pode ser encontrado aqui . O truque é fazer o EF acreditar que todas as tabelas/objectos mapeados estão na mesma base de dados utilizando sinónimos. Eu não sei se todas as BD's suportadas pelo EF têm alguma feature semalhante a sinónimos, mas isto é certamente possível no SQL Server (que eu estou actualmente a usar). O meu script acrescenta a possibilidade de primeiro fazer backup dos ficheiros edmx  (algo que eu acho útil para evitar que o meu modelo fique corrompido), substitui os prefixos no

One of the limitations that EF still has is the support for multiple databases. It simply does not support that option.out of the box. Allthough on UserVoice a lot of people have voted this feature, it still doesn’t exist. Credit where credit is due: this is not my original idea. I first downloaded the original script, used it and then i almost completely rewrote it to suit my needs and to improve certain aspects. I love Linq, so i used it a lot. The original and fantastic script can be found here The trick is making EF believe that those objects are in the database by using synonyms. I dont know if every EF-supported database allows synonyms or not, but this is possible in SQL Server (which i am using).   My script adds the ability to backup the edmx files first (which i find useful to prevent my model from being corrupted), replace the prefixes in the resulting model (which i had to do by hand with the other script) and finally reorder the navigation properties by alphabetica

Antes de mais, vamos definir uma ou duas regras de vocabulário para o artigo: Static - Vou referir-me a esta palavra reservada como a sua tradução literal " Estático". Exemplo: classe estática, método estático... Instance Members   - Esta é uma tradução pobre, eu sei, mas refere-se a membros que apenas estão acessíveis utilizando uma instância de uma determinada classe. Chamar-lhes-ei de membros de instância Isolation Frameworks   - Refiro-me a frameworks que ajudam a criar mocks, fakes e stubs para unit testing . Irei traduzir como Frameworks de Isolamento Em C# 2.0 foi adicionada uma nova funcionalidade denominada por classes e membros estáticos. Quando digo membros refiro-me a métodos, propriedades, eventos, etc. Eu tenho algumas opiniões sobre esta palavra reservada que irei partilhar ao longo do artigo, mas vamos começar por olhar para o que podemos fazer com esta feature . Vejamos este código void Main() { Person p = new Person(); p.Name =

Vamos voltar às minhas traduções dos artigos   sobre a evolução do C#. Todos estamos familiarizados por esta altura com o que é um delegate , correto? Os delegates  são uma parte muito importante do sistema de eventos no .NET. Basicamente, registamos um método (chamado  handler ) num  delegate  que irá ser chamado quando evento é invocado. Por outras palavras, um delegate  simplesmente aponta para um método. É um apontador que tem as vantagens de  type safety  e da abstração de alto nível. A grande vantagem é que um delegate  é um objecto que contém informação sobre como chamar um método, e traz-nos todas as vantagens da utilização de objectos, como por exemplo a capacidade de o passar por parâmetro. Vamos ver: Esta é uma forma de utilizar os  delegates dos eventos.  Uma qualquer classe expõe o evento e nós registamos o método no seu delegate . Quando o delegate  é invocado, todos os métodos registados serão também chamados. O facto de termos vários métodos registados indica que e