E o ADO.NET nunca deve deixar de ser utilizado

Comumente recebo e-mails sobre: “Qual tecnologia de acesso a dados devo utilizar no meu projeto?”, “O EF é performático o suficiente para fazer isso?”, “Tenho uma rotina de acesso a dados lenta, o que devo fazer?”, “Qual a melhor formar de construir minha camada de acesso a dados?”, etc. A resposta para todas essas perguntas é basicamente a mesma. E sempre acabo me referindo ao ADO.NET como um aliado muito forte (e presente) nas aplicações que desenvolvo. Fato este que gera muita surpresa em todos.

Imagem-Animada-How-Do-You-DoWhat

A construção de camadas de acesso a dados é complexa e exige cuidados. Nos últimos anos muito se tem dito e apoiado o uso de ferramentas de mapeamento objeto-relacional (ORM). Tomo como exemplo este blog, onde muitos de meus posts são sobre o Entity Framework.

Saiba mais

About these ads

Entity Framework agora é open source!

Olá pessoal,

entityFrameworkBrasilHoje, o código fonte do Entity Framework esta sendo disponibilizado sob uma licença open source (Apache 2.0) no CodePlex (http://entityframework.codeplex.com/). Esta atitude permitirá que qualquer um na comunidade possa engajar-se e contribuir com correção de bugs e desenvolvimento de novas features.

A Microsoft continuará desenvolvendo compilações oficiais do Entity Framework como os demais produtos. O objetivo de tornar o EF um projeto open source é aumentar o ciclo de feedback de desenvolvimento, favorecendo a construção de um produto ainda melhor.

Saiba mais

SQL Azure – Consultando dados

O SQL Azure é um conjunto de serviços que oferece capacidade de processamento e armazenamento de dados relacionais na nuvem. É a ferramenta que devemos utilizar para armazenarmos dados relacionais de nossa aplicação na plataforma Windows Azure.

No post anterior (http://ferhenriquef.com/2012/04/25/como-criar-um-banco-de-dados-no-sql-azure/) discutimos sobre como criar uma base de dados no SQL Azure, neste post vou demonstrar como acessar o SQL Azure.

Para acessar o SQL Azure não precisamos de nenhum SDK ou configuração especial, apenas precisamos modificar nossa connection string, definindo como server o nome do nosso servidor no Azure. Saiba mais

Entity Framework Code First – Wallpapers

Olá pessoal,

Aproveitando a sequência do post anterior, gostaria de compartilhar com vocês dois wallpapers que fiz sobre o Entity Framework Code First.

efWallpaper01

efWallpaper02

Façam bom uso!

[]s!
Por
Fernando Henrique Inocêncio Borba Ferreira
Microsoft Most Valuable Professional – Data Platform Development

Considerações de Performance do Entity Framework 5

Olá pessoal,

Este post será bastante sucinto. Semana passada o time de ADO.Net liberou um artigo com considerações de performance existentes no Entity Framework 5.

Este artigo é bastante interessante e detalhe diversos aspectos do Entity Framework, tais como:
- Cache
- Opções de execução de queries
- Estratégias de herança
- Lazy loading
- Comparações de performance

Saiba mais

EF41 – Inicializadores de Banco de Dados

Ao trabalharmos com o Entity Framework Code First nos deparamos com diversas convenções. Uma das mais importantes é processo de construção do banco de dados. O Entity Framework 4.1 nos fornece nativamente três inicializadores de banco de dados, sendo eles:

DropCreateDatabaseIfModelChanges:apaga e recria o banco de dados toda vez que alguma alteração no modelo de classes for identificada. Observação: se a tabela EdmMetadata não estiver sendo criada no banco de dados (através da remoção da convention IncludeMetadataConvention), então está opção não irá funcionar e irá disparar uma Exception do tipo NotSupportedException.

CreateDatabaseIfNotExists:cria o banco de dados se o mesmo não existir, se o modelo de classes sofrer alguma alteração será disparada uma exception.

DropCreateDatabaseAlways:apaga e recria o banco de dados sempre, mesmo que nenhuma alteração no modelo de classes tenha sido feita. Saiba mais

Construindo sua camada de acesso a dados com o Entity Framework 4.1

O Entity Framework 4.1(EF41) Code First veio para ajudar os desenvolvedores no processo de construção da camada de acesso a dados de suas aplicações. Ao contrário dos demais modelos do Entity Framework, o modelo Code First tem por objetivo criar o banco de dados seguindo como base a estrutura de nossas classes – os demais modelos, conhecidos como Table First, baseavam a criação das classes no modelo existente em nosso banco de dados. A vantagem da utilização do Code First é a possibilidade de criar um modelo de classes muito mais próximo a nossa necessidade, ao contrário das abordagens anteriores que produziam um modelo de classe “adaptado” de nossa estrutura de banco de dados.

Neste exemplo vamos discutir os modos de implementação de diferentes modelos de relacionamentos (e.g. um-para-muito, muitos-para-muitos, um-para-um) utilizando o ADO.Net Entity Framework 4.1. Além disso, quero mostrar algumas novas features e dar algumas dicas de como nos adequar ao Entity Framework 4.1.

Vamos começar! Alegre

Obs.: Para fazer download do código-fonte acesse este link: http://code.msdn.microsoft.com/Construindo-sua-camada-de-de659425.

1 – Nosso projeto de teste

Para este teste criaremos um cadastro de Clientes, Fabricantes, Produtos e Ordens de Compra. Neste modelo um cliente pode efetuar diversas ordens de compras, sendo que cada comprar pode conter um ou mais produtos, onde cada produto pode estar atrelado a uma ou mais ordens de compra. Além disso, um produto obrigatoriamente contém um fabricante. Nosso diagrama de classes será o seguinte:

diagrama

2 – Camadas da aplicação

Para este exemplo adotei os design patterns MVC e DAO. Os projetos estão dispostos como a imagem a seguir:

Projects

Commerce.Controler: corresponde a camada de controle de nossa aplicação.

Commerce.Entity: possui todas as entidades lógicas de nossa aplicação, além das interfaces que devem ser implementadas pelas demais camadas.

Commerce.Data: responsável pela funcionalidade de armazenamento das informações, esta camada engloba todo o uso do Entity Framework 4.1, diminuindo a dependência do projeto a um tecnologia. Isso permite a fácil manutenção e alteração da tecnologia, sem gerar impactos globais por toda a aplicação.

Commerce.Console: camada de apresentação e consumo dos recursos.

3 – Estratégia de criação da base de dados

Para definir a estratégia de criação do banco de dados fazemos uso de inicializadores.A estratégia default é a DropCreateDatabaseIfModelChanges, que apaga o banco de dados e o recria, além dessa estratégia ainda existem outras duas, sendo elas: DropCreateDatabaseAlways e CreateDatabaseIfNotExists. O time de produto do ADO.Net trabalha hoje em um projeto chamado Code First Migration, que trata do processo de adequação do modelo do banco de dados com as atualizações de suas entidades, sem que seja necessário apagar e recriar o banco de dados. Para fazer uso dos inicializadores de bancos de dados crie em seu DataContext um construtor que defina a estratégia de criação da base de dados como a seguir:

SetInitializer

4 – Remoção de convenções do Entity Framework 4.1

Para efetuar o mapeamento automático de nossas tabelas, o EF41 adota algumas convenções de nomenclatura, tipos de dados, e outros recursos. Para adicionar ou remover convenções devemos sobrescrever o método OnModelCreating de nosso DataContext. Em nosso exemplo removerei duas convenções: IncludeMetadataConvention, que evita a criação da tabela EdmMetada, que é uma tabela que contém um código uma única linha com um código hash utiliza para verificar se o modelo de nosso código é o mesmo do modelo de nosso banco de dados (mais informações aqui: http://blog.oneunicorn.com/2011/04/08/code-first-what-is-that-edmmetadata-table/); e PluralizingTableNameConvention, que é um atributo que evita que a nome das tabelas seja pluralizado, isto é, se você possui uma entidade chamada Carro, a tabela criada automaticamente no banco de dados se chamará Carro, e não Carros como a convenção do EF41 faz.

Conventions

5 – Tipos complexos

É bastante comum em nossas aplicações a necessidade de utilizarmos atributos que apenas servem como “agrupadores” de dados, e que na verdade não deve ser mapeamos em uma única tabela dedicada a eles. Podemos adotar como exemplo um tipo de dados Endereço. Uma classe chamada Endereço é bastante importante para agrupar informações de localidade, mas não possui características que exijam mapeamento para uma tabela dedicada exclusivamente para isso. Diante deste cenário devemos fazer uso do atributo ComplexType. Este atributo quando utilizado indica que nossa classe é um tipo complexo, que não deverá ser persistido em uma tabela própria, e que estará vinculado a atributo de alguma classe. Podemos indicar que uma classe é um tipo complexo de duas maneiras, sendo elas:

2.1 – No corpo da classe, indicando através do atributo ComplexType:

ComplexType01

2.2 – Indicando o tipo complexo em nosso DataContext, dentro do método OnModelCreating:

ComplexType02

Ultimamente tenho pensado que é mais interessante configurar o mapeamento de nossas classes dentro do DataContext do que em nossas classes através da utilização de atributos. Acredito que essa é a melhor forma, pois nosso projeto de entidades ficará livre de mais dependências, necessitando apenas de recursos nativos do Framework .

6 – Entidade base para persistência de dados em fontes de dados

É interessante, ao implementarmos nossas entidades, a criação de uma entidade base que defina atributos obrigatórios para todas as entidades. Neste exemplo criei uma entidade chamada DataEntity que contém três atributos: Id, atributo do tipo inteiro que servirá como chave primária de nossas entidades na base de dados; GlobalId, atributo do tipo GUID que fornecerá um identificador global a nossos registros dentro da base de dados; e Created, atributo do tipo DateTime que informará a data de criação de nossas entidades.

dataEntity

A utilização dessa classe como entidade base exige duas implementações em nossas entidades:

1 – Herança

Herança

2 – Invoque ao construtor da classe base em nossas entidades

construtor

7 – Interface como contrato para os repositórios

Para implementação dos repositórios criei uma interface com um conjunto de métodos obrigatórios que se espera de um repositório.

IRepository

Nessa interface temos as assinaturas:

void Save(T target): este método deve ser responsável pela inclusão e atualização dos dados na base de dados. Uma vez executado deve garantir que os dados serão inclusos ou atualizados conforme a entidade passada por parâmetro.

void Delete(T target): método de exclusão de registros da base de dados. Quando invocado, deve apagar o registro passado por parâmetro da base de dados.

T GetById(int id): método que deve retornar o registro na base de dados que contiver em sua chave primária o valor passado por parâmetro.

T GetByGlobalId(Guid id): gosto bastante de utilizar um campo UNIQUEIDENTIFIER em meus registros, pois atribuímos ao registro uma chave de identificação única que o torna único em todo o banco de dados, independente de sua localização – assim como propostos em bases de dados orientadas a objetos.

IEnumerable<T> GetAll(): deve retornar todos os registros existentes na base de dados para a entidade consultada.

IEnumerable<T> ExecuteQuery(Func<T, bool> expression): este método faz consultas na base de dados utilizando como filtro a expressão passada por parâmetro.

Esta interface define o que é esperado por cada classe repositório, mas se notarmos ela utiliza um tipo genérico como parâmetro para sua implementação. Para refinarmos o seu uso e tornarmos nosso repositório reutilizável e expansível, acredito que devemos criar para cada classe repositório uma interface que implemente o contrato definido por IRepository<T>, mas que defina qual entidade será persistida ali. Tomemos como exemplo a interface do repositório de clientes, conforme código:

IClientRepository

Seu classe repositório deve implementar ICLientRepository e ser igual a seguinte implementação:

ClientRepository

Observem que nossa classe de repositório implementa a interface IClientRepository utilizando a entidade Client como alvo de nossas ações de persistência no banco de dados, e não um tipo de dados genérico, como utilizado na interface IRepository<T>.

Este uso é indicado ao construirmos nossos testes unitários, pois ao implementarmos nossos repositórios fakes já teremos nossos repositórios bem estruturados e prontos para extensão.

Outra dica para a construção de nossos testes unitários é tornar os repositórios parametrizáveis através de nossas classes controllers. Devemos criar uma assinatura de construtor que permita a parametrização do repositório que utilizaremos em nossa implementação, assim como é importante fornecer um construtor que defina um repositório padrão, caso não seja passado nenhum parâmetro para o repositório, podemos fazer isso desta forma:

clientController

Bom, espero que algumas dicas aqui descritas ajudem a implementação de suas aplicações com o Entity Framework 4.1. Bom estudo e continuem programando… Alegre

[]s!

Por
Fernando Henrique Inocêncio Borba Ferreira

Entity Framework 4.1 + MVC + DAO

Neste exemplo vamos demonstrar o uso dos design patterns MVC e DAO, combinados com a utilização do Entity Framework 4.1 como tecnologia de acesso a dados de nossa aplicação.

O MVC (Model-View-Controller) é um design pattern bastante utilizado no mercado devido a sua capacidade de dividir a aplicação em camadas especialistas em suas funções, favorecendo a alta coesão das mesmas. A camada model é responsável por representar o mundo real através do uso de objetos. A camada view é dedicada exclusivamente a apresentação dos dados, podendo ser uma aplicação web, uma aplicação console, um formulário do Windows, uma page Silverlight, ou qualquer outra tecnologia front-end. A camada controller faz ponte entre a camada view e a camada model, interceptando a comunicação entre as duas e aplicando regras, validações, redirecionamentos ou encapsulando a comunicação com diferentes frameworks e sistemas. Outra vantagem deste modelo é a possibilidade de criar módulos independentes que trabalhem de modo desacoplado, para que se tornem fáceis de serem substituídos e reutilizados.

O design pattern DAO (Data Access Object) tem o objetivo de encapsular todos os acessos as fontes de dados feitas na aplicação. O uso deste design pattern permite que nossa aplicação não fique dependente de uma tecnologia de acesso a dados, pois estaremos agrupando todas as regras e usos de frameworks específicos de acesso a dados em uma única camada que pode ser facilmente substituída. Caso seja necessária a substituição da tecnologia de armazenamento (exemplo: de MS SQL para Oracle, ou de MS SQL para SQL Azure, ou de Oracle para alguma tecnologia NoSQL) o impacto não será tão grande, e a adaptação do sistema será restrita, evitando impactos globais na aplicação.

Mãos a obra

Pare demonstrar o uso destes design patterns e do Entity Framework 4.1 criaremos um cadastro simples de carros e suas respectivas montadoras.

1 – Abra o Microsoft Visual Studio 2010 e crie uma solução em branco.
2 – Adicione um projeto class library, no nosso exemplo este projeto chamará SampleCore.
3 – Apague o arquivo “Class1.cs” que é criado automaticamente pelo Visual Studio. Faça referências ao namespace “System.Data.Entity” e ao Entity Framework 4.1, geralmente esta localizado no caminho C:\Program Files (x86)\Microsoft ADO.NET Entity Framework 4.1\Binaries\EntityFramework.dll, o download do EF 4.1 pode ser feito neste link: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=8363
4 – Crie três pastas dentro do projeto, chamadas Model, Controller e Data.
5 – Crie as classes Carro e Montadora dentro de Model conforme os exemplos a seguir:

01

02

Observe que para representar o relacionamento um para muitos (entre a montadora e os carros) utilizamos o tipo de dados ObservableCollection. ObservableCollection representa uma coleção de dados dinâmica que fornece notificações quando os itens são adicionados, removidos ou quando toda a lista é atualizada.

6 – Agora vamos começar a trabalhar com nossa camada de acesso a dados. Antes de qualquer coisa, criaremos duas interfaces para nossos repositórios de montadoras e carros. As interfaces devem ser criadas dentro de Model e devem implementar a seguinte estrutura:

03

04

Crie dentro da pasta Data uma classe chamada ContextoBancoDados e faça-a herdar de DbContext (namespace System.Data.Entity dentro do assembly EntityFramework.dll). E implemente-o conforme o código abaixo:

05

Caso o banco de dados não exista, e nenhuma string conexão tenha sido fornececida, então será criada uma base de dados local, cujo nome será igual a assinatura da classe dbcontext, isto é, o namespace da qual a classe pertence concatenado com o nome da classe dbcontext. Por exemplo, se sua classe dbcontext pertencer ao namespace “NomeDoCliente.NomeDoProjeto.Repositorio” e sua classe datacontext se chamar “ContextoBancoDados” então o nome de seu banco de dados será  “NomeDoCliente.NomeDoProjeto.Repositorio.ContextoBancoDados”… Não parece ser uma boa prática um nome deste tamanho com características de nomenclatura tão específicas, então recomendo que sempre seja informada uma string de conexão, como no exemplo anterior.

Obs.: Para este exemplo deixei a string de conexão fixa (“chumbada”) no código… Esta realmente não é uma boa prática, o melhor neste caso é deixar a string de conexão em um arquivo configurável de sua aplicação. Para este cenário procure utilizar recursos nativos, como os arquivos App.Config e Web.Config.

7 – Para garantir a criação de seu banco de dados no primeiro acesso procure deixar fixo em algum lugar estratégico de sua aplicação a chamada para o método de criação da base. Não é uma boa prática tornar esse bloco de criação do banco de dados algo que será sempre validado e executado, pois isso pode consumir tempo e recursos operacionais. Então, como dica, os dois locais que acredito serem os ideais para este tipo de procedimento:
– Evento Application Start do Global.asax – no caso de aplicações web.
– Método Main() do arquivo Program.cs – no caso de aplicações desktop e console.

Mais para frente, neste mesmo post, irei demonstrar os comandos necessários para criação do banco de dados.

8 – Para implementação do design pattern DAO e utilização do Entity Framework 4.1 implementaremos as classes RepositorioMontadora e RepositorioCarro dentro da pasta Data da seguinte forma:

060

070

Para encapsular os comandos de criação do banco de dados, encapsularemos seu comportamento em uma classe chamada BancoDadosRepositorio implementada por uma interface chamada IFonteDadosRepositorio, conforme o código a seguir:

090

080

9 – Agora que temos criadas nossas entidades e nossos repositórios, poderemos implementar nossa classe controller que irá gerenciar os acessos as nossas fontes de dados, além de fazer ponte com nossa camada de visão. Nesta classe, por conta da simplicidade de nosso exemplo, iremos implementar as regras de persistência das montadoras e dos carros no mesmo controller. Da seguinte maneira:

100

10 – Nesses momentos já temos nossa camada de DAO pronta, além das camadas model e controller (pertencentes ao MVC) também concluídas. O próximo passo agora é implementar a camada de visão. Para este exemplo criaremos uma aplicação console, pois no momento a estrutura de nossa aplicação tem maior relevância do que a interface. Nesta demonstração criamos uma aplicação console chamada SampleConsole, e fizemos referência para o projeto SampleCore, para que conseguíssemos acessar suas classes. Nossa aplicação console deverá se parecer com algo como:

110

A estrutura da aplicação deve ficar como a imagem a seguir:

00000

Para fazer o download acesse este link: http://code.msdn.microsoft.com/Entity-Framework-41-MVC-DAO-4860e78c

Por
Fernando Henrique Inocêncio Borba Ferreira.

Atualizando dados utilizando o método Attach!!!!

O modo mais fácil de atualizarmos dados de nosso modelo no banco de dados é através do método Attach. Assim como utilizamos o InsertOnSumit para executarmos inclusões na base de dados, o método Attach pode ser bastante útil para atualizações de nossas entidades em nossas bases de dados.

Vamos supor uma classe chamada Arquivo:

AttachArquivo01

… e vamos utilizar uma data context como o seguinte:

AttachDataContext02

Em seguida, vamos criar um método para submeter nossas atualizações ao banco de dados:

AttachSalvar03

Observe que caso o valor de nossa propriedade Id seja distinto de ZERO, teremos de executar uma consulta na base de dados para retornar a instância que desejamos e assim fazermos o “de/para” dos dados de nossa instância (com valores atualizados) para a instância vinda do banco de dados.

Se utilizássemos o método Attach iríamos reduzir a complexidade deste código e removeríamos uma consulta desnecessária ao banco de dados para buscar a instância que lá existe, desta maneira:

AttachSalvar04

Simples! Veja que a complexidade do código foi reduzida e eliminamos uma consulta extra ao banco de dados, o que acaba gerando uma rotina de atualização mais rápida e performática.

Mas existe uma ressalva sobre este método: o Attach EXIGE que a instância de objeto passada por parâmetro não esteja vinculada a nenhum outro Data Context, isto é, caso a instância de objeto passada por parâmetro para o método Salvar tenha vindo diretamente de um Data Context, o attach não ocorrerá, e receberemos uma mensagem de erro, por isso, neste caso, a classe Arquivo implementa a interface ICloneable, resultando nesta estrutura:

AttachArquivo05

[]s e até a próxima! =]

 

Por
Fernando Henrique Inocêncio Borba Ferreira.

Utilizando ADO.Net POCO Entity Generator

Uma nova abordagem de mapeamento objeto-relacional é o POCO (Plain Old CLR Object), que permite a utilização de nossas próprias classes como entidades dentro do modelo de mapeamento. Esta abordagem preza a utilização de classes simples, que não façam referência a frameworks especializados, que não dependam de soluções de terceiros, que não implementem nenhuma interface especial e que não dependam de nenhuma hierarquia de namespace.

O ADO.Net POCO Entity Generator é um template do Visual Studio 2010 que auxilia na construção de projetos que adotem o POCO criando entidades a partir de um modelo de dados. Neste post veremos quais os passos necessários para adoção desta técnica em projetos e como utilizar este template do Visual Studio 2010.

1 – Crie a tabela Person no banco de dados, conforme o script SQL abaixo:

clip_image002

2 – Crie uma solution no Visual Studio 2010 em branco.

clip_image004

3 – Adicione dois projetos Class Library a solution, a estes novos projetos atribua os nomes Data e Entities.

clip_image006

4 – Selecione o projeto Data e adicione um novo item utilizando o template ADO.Net Entity Data Model. No exemplo, criei com o nome dbModel.edmx. Este item é aquele comumente utilizado para adições de mapeamentos objeto-relacionais através do Entity Framework. Nas telas seguintes devem ser definidas: a conexão com o banco de dados e as tabelas que serão mapeadas. Neste exemplo apenas mapeei a tabela Person.

clip_image008
clip_image010

5 – Após fazer o mapeamento utilizando o Entity Framework, será preciso instalar o template ADO.Net POCO Entity Generator (caso o mesmo não esteja instalado). Clique em “Tools/Extension Manager”, selecione a aba Online Gallery e na caixa de pesquisa (localiza no canto superior direito) e pesquise por “T4”. Após a exibição dos resultados, instale os templates: “ADO.Net C# POCO Entity Generator” e “ADO.Net C# Web Site POCO Entity Generator” (caso a sua linguagem preferida seja VB.Net, então instale os templates próprios para a mesma, eles também estão disponíveis no resultado da consulta feita anteriormente).

clip_image012

clip_image014

6 – Após o download dos templates, volte a ferramenta de mapeamento, clique com o botão direito sobre uma das entidades mapeadas e seleciona a opção “Add Code Generation Item”.
clip_image016
7 – Adicione um novo item utilizando o template ADO.Net POCO Entity Generator. Neste exemplo atribui o nome “ModelPoco.tt”.

clip_image018

8 – Serão criados dois arquivos “ModelPoco.Context.tt” e “ModelPoco.tt”. O arquivo “ModePoco.tt” constrói as entidades, enquanto que o arquivo “ModelPco.Context.tt” gera o contexto tipado. Mova o arquivo “ModePoco.tt” Para o projeto Entities, a fim deixar o projeto classe projeto com suas respectivas responsabilidades separadas, sendo: Data, com acesso aos dados e o Entities, representando as entidades. Adicione no projeto Data referência para o projeto Entities.

clip_image020

9 – Dentro de “Modelo.tt”, na linha 22, altere o caminho do arquivo de mapeamento do Entity Framework para “..\Data\dbModel.edmx”. Isso fará com que a geração das entidades aponte para o arquivo correto, já que mudamos o arquivo de projeto.

clip_image022

Dentro de “ModelPoco.Context.tt”, vá até a linha 44, adicione uma referência para Entities, para que a geração de estruturas POCO possa identificar os tipos de dados utilizados no contexto.

clip_image024

Acesse as propriedades do arquivo “ModelPoco.tt” e altere a propriedade Custom Tool Namespace para “Entities”, faça o mesmo para o arquivo “ModelPoco.Context.tt”, mas modifique o valor da propriedade Custom Tool Namespace para “Data”. Esse passo é importante para que a geração de dados seja feita utilizando os namespaces previstos.

10 – Para testar o código, dentro da solution, crie um novo projeto utilizando o template Console Application. Dentro deste novo projeto faça referência as DLLs: Data, Entities e System.Data.Entity. Copie o arquivo “App.Config” que está localizado no projeto Data para este novo projeto, este passo é importante pois a string de conexão está localizada no mesmo.

clip_image026

11 – Para inserir novos registros utilize o código a seguir:

clip_image028

12 – Para consultar dados da base de dados utilize o código a seguir:

clip_image030

[]s! e até o próximo…

 

Por
Fernando Henrique Inocêncio Borba Ferreira.

Seguir

Obtenha todo post novo entregue na sua caixa de entrada.

Junte-se a 64 outros seguidores