Waldemir Cambiucci - Solutions Architect - Microsoft Brasil

Olá Acaz, tudo certo?

Obrigado pelos comentários! :)

De fato, iBATIS e HIBERNATE são frameworks de persistência que oferecem versões para o mundo .NET. Nascido no mundo Java, o iBATIS tem a versão iBATIS.NET, assim como o HIBERNATE tem a versão NHIBERNATE.

Se sua aplicação está no mundo .NET, LINQ torna-se agora uma nova alternativa para sua implementação na camada de persistência, fazendo esse mapeamento objeto-relacional (ORM).

O que recomendo de fato é que você faça testes, que experimente as tecnologias.

Pessoalmente, aposto na dupla LINQ + ADO.NET Entity Framework, devido sua natureza flexível quanto ao uso de múltiplos bancos ou múltiplas fontes de dados. Se o cenário envolve o uso de Microsoft SQL Server, o LINQ se torna ainda mais atraente, pois através de uma única classe LINQ TO SQL, você fará o mapeamento de tabelas no mundo OO, sem mesmo a necessidade do ADO.NET Entity Framework.

Veja um exemplo de LINQ TO SQL a seguir:

//////////////////////////////////////////////////////////////////////////////////////

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Data.Linq;

namespace LINQtoSQL

{

   class Program

   {

       static void Main(string[] args)

       {

           // Contexto de acesso ao banco de dados.

           DataContext context = new DataContext("Data Source=.\\SQLEXPRESS;AttachDbFilename=C:\\LINQtoSQL\\petdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True");

           // Representação das tabela remota People.

           Table<People> people = context.GetTable<People>();

           // Construindo a consulta LINQtoSQL.

           var query = from p in people

                   where p.Age >= 30

                   select new { p.Name, p.Age, p.CanCode };

           // Executando a consulta LINQ.

           foreach(var item in query)

           {

               Console.WriteLine("Name: {0} - Age: {1} - CanCode: {2}",

                   item.Name, item.Age, item.CanCode);

           }

       }

   }

}

//////////////////////////////////////////////////////////////////////////////////////

O exemplo acima faz uma consulta ao banco petdb.mdf, onde a tabela People é percorrida via LINQ.

Para saber mais, veja o link...

LINQ to SQL

Ref.: http://msdn2.microsoft.com/en-us/library/bb386976.aspx

Depois me conta o que você decidiu! :)

[]'s

Waldemir

Olá Acaz, tudo certo?

O importante é continuar acompanhando a evolução do ADO.NET Entity Framework, que já está em Beta 3.

De fato, trabalhar com o LINQ to SQL exigirá a instalação do .NET 3.0 + .NET 3.0 SP1 + .NET 3.5.

Mas tudo isso mantendo a compatibilidade com as aplicações em .NET 2.0, lembre-se disso.

Veja o link e trecho a seguir:

Deploying Microsoft .NET Framework Version 3.0

Ref.: http://msdn2.microsoft.com/en-us/library/aa480198.aspx

De onde temos:

"The Microsoft .NET Framework 3.0 is the new managed code programming model for Windows®. It combines the power of the .NET Framework version 2.0 with new technologies for building applications that have visually compelling user experiences, seamless communication across technology boundaries, and the ability to support a wide range of business processes. These new technologies are Windows Presentation Foundation, Windows Communication Foundation, Windows Workflow Foundation, and Windows CardSpace. The .NET Framework 3.0 is included as part of the Windows Vista™ operating system; you can install it or uninstall it using Windows Features Control Panel.

The .NET Framework 3.0 adds new technologies to the .NET Framework 2.0, which makes the .NET Framework 3.0 a superset of the .NET Framework 2.0. You can think of .NET Framework 3.0 as an "additive" release to the .NET Framework 2.0, as contrasted with a generational release where software is revised across the board. (For example, the .NET Framework 2.0 was a generational release over the .NET Framework 1.0.)

Because .NET Framework 3.0 is an additive release and uses the core run-time components from .NET Framework 2.0, it is completely backward compatible with the earlier version. Your existing .NET Framework 2.0 based-applications will continue to run without any modifications and you can safely continue your investments using the technologies that shipped with .NET Framework 2.0."

Por enquanto é só!

[]'s

Waldemir.

Olá Diogo, tudo certo?

Obrigado pelos comentários.

De fato, lembre-se que tudo está ainda em desenvolvimento, alguns em Beta, outros em CTP e outros em CodePlex. Ou seja, muito espaço para direcionamento e sugestões.

E ainda: o Data Services, o Entity Framework e o Sync estão sob o mesmo projeto, o ADO.NET vNext.

Creio que ainda veremos alguns alinhamentos nesses frameworks.

Vale acompanhar o blog do time de ADO.NET, com certeza:)

ADO.NET team blog

Ref.: http://blogs.msdn.com/adonet/

[]'s

Waldemir.

Olá Fabiano, tudo certo?

Obrigado pelos comentários no blog!

Com certeza, discutir LINQ e EF é muito importante, assim como realizar bons testes e provas de conceito, para uma boa decisão de projeto.

Para suas perguntas, veja alguns comentários:

>> Utilizando o Linq to SQL ele gera os objetos automaticos a duvida é, não terei uma classe gigante que se tornará lenta e muito grande ao longo do tempo?

[wcamb] De fato não. É importante que no momento de geração de cada classe, você escolha as entidades que serão implementadas. Assim, cada entidade pode estar em dataclasses separadas, o que irá permitir um bom mapeamento de relacionamento e possíveis alterações das entidades. Um exemplo seria agrupar tabelas e relacionamentos afins em DataClasses específicas, eviando-se um mapeamento de todas as entidades numa única DataClasses.

>> O ADO.NET Entity Framework trabalha melhor isso?

[wcamb] Creio que a abordagem seria a mesma. Note que o LINQ to SQL não implementa uma camada de abstração, o que de fato muda a forma de instância e acesso aos objetos internos mapeados.

Como exemplo, pense num projeto LINQ TO SQL, onde usamos dois arquivos .DBML, um para cada DataClass mapeamento um grupo de objetos específicos. O acesso as tabelas ficaria assim:

static void Main(string[] args)

{

   // Contexto de acesso ao banco de dados.

   DataContext context = new DataContext("Data Source=.\\SQLEXPRESS;AttachDbFilename=C:\\Database\\petdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True");

   // Representação das tabelas remotas do DataClass1

   Table<People> people = context.GetTable<People>();

   // Representação das tabelas remotas do DataClass2

   Table<Order> order = context.GetTable<Order>();

   // Construindo a consulta LINQ.

   var query = from p in people

   where p.Age >= 40

   select new {p.Name, p.Age, p.CanCode };

   // Executando a consulta LINQ.

   foreach(var item in query)

   {

Console.WriteLine("Name: {0} - Age: {1} - CanCode: {2}",

   item.Name, item.Age, item.CanCode);

   }

}

[wcamb] Ou seja, não tenho impacto de programação, uma vez que ambos os dataclasses estão no mesmo namespace, sobre o mesmo banco de dados:

[System.Data.Linq.Mapping.DatabaseAttribute(Name="petdb")]

public partial class DataClasses1DataContext : System.Data.Linq.DataContext

[System.Data.Linq.Mapping.DatabaseAttribute(Name="petdb")]

public partial class DataClasses2DataContext : System.Data.Linq.DataContext

[wcamb] Um ponto de impacto sim será na qualidade do seu modelo de dados. Nesse ponto, vale bons testes com diferentes complexidades de modelos para ver o comportamento. O blog do Dany Simons é uma boa referência sobre essa discussão, vou reler também :)

Ref.: http://blogs.msdn.com/dsimmons/pages/entity-framework-faq.aspx

>> Devo ter uma segunda camada de negocio ou juntar tudo nas classes geradas pelo linq.?

[wcamb] Minha sugestão é separar, isto é, deixar suas implementações de negócio em classes separadas das classes de mapeamento das entidades do LINQ to SQL. O mesmo vale quando estiver usando EF. Isso garante que, caso haja qualquer alteração ou update de mapeamento (e elas acontecerão), você não tenha surpresas como perda de customizações que tenha feito diretamente nos mapeamentos. Na verdade, mesmo essas customizações eu recomendo ter cuidado.

>> Qual seria a melhor estrutura visando um reaproveitamento legal e performance?

[wcamb] Quando a performance, recomendo ver o artigo a seguir:

Ref.: http://visualstudiomagazine.com/features/article.aspx?editorialsid=2372

[wcamb] Quanto ao reaproveitamento, creio que manter a simples separação entre customizações de negócio e classes de mapeamento já seja uma boa abordagem. Mas ainda pretendo consolidar um material melhor sobre melhores práticas para projetos LINQ e EF. Aguarde!

>> não sei se consegui ser claro!

[wcamb] conseguiu sim. Em linhas gerais, como manter o mapeamento de entidades do modelo de dados no projeto usando LINQ to SQL ou EF e quais seriam boas práticas de reuso e performance. São perguntas muito pertinentes.

>> mais acho que esse duvida que tambem e acompanhada de um pouco de falta de conhecimento pode gerar uma palta legal.

[wcamb] acompanhar os blogs indicados e bons exemplos é um bom caminho, pois a comunidade tem participado ativamente com dicas e questões semelhantes. Por isso, sejam benvindas as perguntas :)

Por enquanto é só!

[]s

Waldemir.

Olá Manuel, tudo certo?

Obrigado pelos comentários no blog!

Sem dúvida, meu exemplo foi simple e ainda baseado apenas em LINQ TO SQL. De fato, utilizei o Server Explorer para uma conexão com um banco .mdf local.

Assim, meu DataContext ficou apontado para o arquivo exemplo, como abaixo:

// Contexto de acesso ao banco de dados.

DataContext context = new DataContext("Data Source=.\\SQLEXPRESS;AttachDbFilename=C:\\Demo_LINQtoSQL\\petdb.mdf;Integrated Security=True;Connect Timeout=30;User Instance=True");

Para cenários de acesso remoto, vale utilizar uma variável para ConnectionString em arquivo de configuração ou em serviço que seja consultado para devolver a string desejada e permitida:

Vejamos um exemplo: no arquivo Web.config ou App.config da aplicação, podemos ter a connectionString de necessária.

No exemplo abaixo, tenho a string "myConnectionString".

<connectionStrings>

<add name="myConnectionString" connectionString="Data Source=.\sqlexpress;Initial Catalog=MyDataBase;Integrated Security=True" providerName="System.Data.SqlClient"/>

</connectionStrings>

Com essa string, fazemos a conexão ao banco desejado, conforme abaixo:

Public Sub DataAccess()

           Dim objConnectionStringSettings As ConnectionStringSettings = ConfigurationManager.ConnectionStrings("myConnectionString")

           strConnectionString = objConnectionStringSettings.ConnectionString

           Dim cnn As New SqlConnection()

           cnn.ConnectionString = strConnectionString

End Sub

ou em C#...

public DataAccess()

{

SqlConnection cnn = new SqlConnection(ConfigurationManager.ConnectionStrings["myConnectionString"].ToString());

}

A partir desta conexão, podemos criar as instâncias de tabelas e stored procs que serão consumidas e navegadas através de LINQ.

Alguns exemplos interessantes você ainda encontra aqui:

http://www.dotnetjunkies.ddj.com/QuickStartv20/aspnet/doc/management/retrieve.aspx#connectionstrings

Depois diga-me se ajudou! :)

[]s

Waldemir.

Olá Funny,

Obrigado pelos comentários no blog.

Existem duas opções aqui:

>> ou aplicamos o modelo IPOCO - Interface Plain Old CSharp Object do Entity Framework (se estivemos usando LINQ TO ENTITY + ADO.NET Entity Framework).

Veja as discussões abaixo:

Ref.: http://www.sitechno.com/Blog/IntroducingEntityFrameworkContribEasyIPocoImplementationV01.aspx

Ref.: http://blogs.msdn.com/dsimmons/archive/2007/06/02/persistence-ignorance-ok-i-think-i-get-it-now.aspx

>> ou sendo uma solução Web, avaliamos o ASP.NET Dynamic Data, que permite essa integração de forma direta, veja:

Ref.: http://davidhayden.com/blog/dave/archive/2008/04/19/ASPNETDynamicDataWizardGeneratingLINQToSQLDataModelCustomPages.aspx

Ref.: http://weblogs.asp.net/scottguportuguese/archive/2008/04/10/preview-do-asp-net-dynamic-data-dados-dinamicos-asp-net-disponivel.aspx

Espero que ajude!

Waldemir.