Desenvolvendo com Entity Framework + MySQL (Parte 1)

@update 1: Quando escrevi essas dicas estava usando o Windows Vista, no Windows 7 tive que usar uma sintaxe diferente dentro do arquivo my.ini:

set-variable = lower_case_table_names=2

@update 2: Para editar arquivos no notepad como administrador você pode entrar no prompt de comando no modo administrador, navegar até a pasta onde se encontra o arquivo e digitar notepad my.ini

Instalando o MySQL no Windows

Basicamente pode fazer a instalação default. Na tela de configuração de serviço você vai ter direito a escolher três opções de trabalho, eu recomendo que escolha Transactional Database Only. Isso porque o tipo de tabela padrão será definido como InnoDB. O que normalmente será verdade para podermos criar os relacionamentos. Todas as tabelas precisam ser definidas como InnoDB para que existam mapeamento de relacionamento entre elas.

Configuração para o nome das tabelas ficarem case-sensitive

Você tem que abrir o arquivo my.ini que está na pasta do MySQL (Arquivos de programas) e adicionar ao final do arquivo as seguintes linhas:

[mysqld]
lower_case_table_names=2

Note que você vai precisar editar o arquivo como Administrador.

Recomendações

  1. Intale as ferramentas em modo gráfico para administração: http://dev.mysql.com/downloads/gui-tools/5.0.html
  2. Nas chaves não use o tipo Integer padrão do MySQL, use INT(11) no local. Isso é importante na hora de mapear no Entity Framework. Lembre também de desmarcar o UNSIGNED.
  3. Verifique se a tabela está definida como InnoDB e não MyISAM. Isso é importante para criar os relacionamentos.
Anúncios

Providers para o Entity Framework

Antes, para saber quais os providers disponíveis para EF era necessário ficar vasculhando o blog da equipe do ADO.NET. Felizmente resolveram concentrar essa informação na página principal do site do EF aqui e criaram também uma página apenas para isso aqui.

Links

Futuro do LINQ to SQL e Entity Framework

Finalmente a Microsoft resolveu se pronunciar oficialmente sobre o futuro das duas frameworks. O anuncio partiu de Tim Mallalieu direto do blog do ADO.NET, aqui nesse post.

So what exactly is the announcement about?

Over the last few months we have been looking at how to carry forward LINQ to SQL and LINQ to Entities. At first glance one may assert that they are differentiated technologies and can be evolved separately. The problem is that the intersection of capabilities is already quite large and the asks from users of each technology takes the products on a rapid feature convergence path. For example, common asks for LINQ to Entities (that are being delivered with .NET 4.0) are POCO and Lazy Load.  Similarly, in the LINQ to SQL side we are being asked to provide new mapping strategies and other features which the EF already has. Additionally there are common asks for new features like UDT’s and better N-Tier support for both stacks. The announcement really centers around the point that,  after looking hard  at this and triangulating with internal partners and customers, we decided to take the EF forward with regards to the overall convergence effort and over time provide a single solution that can address the various asks.

Is LINQ to SQL Dead?

We will continue make some investments in LINQ to SQL based on customer feedback. This post was about making our intentions for future innovation clear and to call out the fact that as of .NET 4.0, LINQ to Entities will be the recommended data access solution for LINQ to relational scenarios. As mentioned, we have been working on this decision for the last few months. When we made the decision, we felt that it was important to immediately to let the community know. We knew that being open about this would result in a lot of feedback from the community, but it was important to be transparent about what we are doing as early as possible.  We want to get this information out to developers so that you know where we’re headed and can factor that in when you’re deciding how to build future applications on .NET.  We also want to get your feedback on the key experiences in LINQ to SQL that we need to add in to LINQ to Entities in order to enable the same simple scenarios that brought you to use LINQ to SQL in the first place.

Tradução:

Então sobre o que exatamente se trata o anúncio?

Nos últimos meses, temos analisado como levar adiante o LINQ to SQL e o LINQ to Entities. À primeira vista alguém pode afirmar que eles são tecnologias diferentes e podem ser evoluídas separadamente. O problema é que o cruzamento das capacidades já é bastante grande e as solicitações dos usuários de cada tecnologia leva os produtos a uma rápida convergência de funcionalidades. Por exemplo, solicitações comuns para o LINQ to Entities (que estão sendo entregues com .NET 4.0) são POCO e Lazy Load. Do mesmo modo, no LINQ to SQL somos chamados a oferecer novas estratégias de mapeamento e outros recursos que a EF já possui. Além disso, existem solicitações de novos recursos como da UDT e maior apoio para N-camadas em ambos os blocos. O anúncio realmente centra no ponto que, depois de uma difícil análise com clientes e parceiros, estamos decididos tomar a EF em frente no que diz respeito ao esforço global de convergência ao longo do tempo e fornecer uma solução única para que poassa atender as diferentes solicitações.

LINQ to SQL está morto?

Vamos continuar a fazer alguns investimentos no LINQ to SQL baseado no feedback dos clientes. Este post foi para tornar clara a nossa intenção sobre futuras inovações e para o fato de que, assim como o .NET 4.0, o LINQ to Entities será a solução recomendada para acesso aos dados relacional. Como mencionado, temos trabalhado nessa decisão pelos últimos meses. Quando tomamos a decisão, sentimos que era importante que a comunidade ficasse sabendo imediatamente. Sabíamos que estar aberto sobre isso resultaria em um monte de informações por parte da comunidade, mas era importante ser transparente sobre o que estamos fazendo o mais cedo possível. Queremos levar essa informação para os desenvolvedores de modo que você saiba onde estamos com a cabeça e decidir como estará construindo suas futuras aplicações em .NET. Também queremos obter comentários sobre as principais experiências em LINQ to SQL que precisamos adicionar também ao LINQ to Entities de modo a permitir que os mesmos cenários simples que te levaram a usar o LINQ to SQL possam ser implementados no LINQ to Entities.

%d blogueiros gostam disto: