Net framework

31/07/2018 .NET Framework
https://msdn.microsoft.com/pt-br/library/cc580576(d=printer).aspx 1/7
.NET Framework
Estratégia de acesso a dados para o Microsoft .NET Compact Framework
Artigo original encontra-se em
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppc2k2/html/dataaccessstrategy.asp
Se aplica para:
    Microsoft® .NET Compact Framework 1.0
    Microsoft SQL Server™ 2000 Windows® CE Edition
    Microsoft Windows Powered Pocket PC
Resumo:
O .NET Compact Framework pode forçar a comunicação e aplicação de troca de dados entre dispositivos móveis e
servidores de diversas formas. Isto é importante para definir uma sólida estratégia de acesso a dados antes de desenhar,
desenvolver e instalar soluções em relação a cada método com características diferentes. Este artigo aborda as opções
chaves: os baseados em XML e aqueles baseados em SQL Server CE. A importância de definir uma estratégia de acesso a
dados é crítica uma vez que levará a mais eficiência e menor tendência a erros no desenvolvimento e instalação.
Introdução
O principal foco deste artigo, do ponto de vista de dispositivos, é a plataforma Pocket PC. Entretanto, o Microsoft® .NET
Compact Framework também roda em dispositivos Microsoft Windows® CE .NET que implementa outros fatores do que
o Pocket PC. Os conceitos do .NET Compact Framework discutidos aqui podem ser aplicados para estes dispositivos
também.
Uma estratégia de acesso a dados no .NET Compact Framework lida com um número de aspectos. O aspecto chave, com
o qual outros dependem, é a conectividade. Assim como o Pocket PC pode ser usado tanto online como offline, a
estratégia de acesso a dados precisa definir:
• Administrar e usar dados nos servidores remotos quando online
• Armazenar e usar dados quando offline
• Trocar dados quando o Pocket PC fica online a partir de um estado offline anterior
No contexto da estratégia de acesso a dados é importante para estabelecer uma terminologia comum. Isto é verdadeiro
em se tratando de troca de dados entre Pocket PC e o servidor. A partir de uma perspectiva conceitual, existem dois
métodos para troca de dados: sincronização e transferência de dados.
Sincronização de dados suporta trocas de dados em ambas as direções e implementa funcionalidades para assegurar
que os dados são idênticos nos dois lados. Em muitos cenários, o mesmo dado pode ser modificado em múltiplos
lugares enquanto os Pocket PCs estão offline, e então, sincronizados com o servidor. Sincronização deverá funcionar,
entretanto, freqüentemente inclui resolver conflitos que lidam com concorrência que ocorre quando um Pocket PC
desconectado retorna online para sincronizar dados. Um exemplo deste cenário ocorre quando um comprador móvel
atualiza no pedido o campo enquanto inicia offline. Antes de o comprador sincronizar as trocas, um representante
atualiza o mesmo pedido. Um cuidadoso desenho da resolução de conflitos pode determinar quais ações tomar quando
ocorrer conflitos, por exemplo, o comprador móvel exceder o comprador baseado no cargo ou tempo de sincronização,
ou se o sistema deverá notificar um usuário ou grupo de usuários com uma mensagem que ocorreu um conflito.
Transferência de dados também suporta trocar dados em ambas as direções, mas não existe funcionalidade para
assegurar que os dados em ambos lugares sejam idênticos e não existe resolução de conflitos. Existem muitos cenários

onde a transferência de dados é um método válido e onde a sincronização de dados não é necessária. Exemplos de um
cenário de transferência de dados inclui transferência estática de dados do servidor para o Pocket PC, transferir somente
novas coleções de dados do Pocket PC para o servidor, e transferir dados para e dos Pocket PCs que explicitamente está
checado dentro e fora ou segmentado para usuários individuais, marcando os dados como somente leitura no servidor
enquanto está checado fora ou selecionado para um usuário específico.
O uso dos termos “sincronização de dados” e “transferência de dados” irão refletir suas verdadeiras idéias e quando
ambos estão implícitos nos termos “troca de dados” serão usados.
Aspectos da Estratégia de Acesso a Dados
Fundamentalmente, a estratégia de acesso a dados do .NET Compact Framework se divide em dois aspectos:
1. Como armazenar dados no Pocket PC. Do ponto de vista da aplicação, dados podem ser persistidos em um banco de
dados relacional (como um Microsoft SQL Server™ CE), em arquivos locais (como arquivos XML muitas vezes gerenciados
através de DataSets), e dados estruturados na memória (Session) que estão dispostos quando a aplicação é encerrada.
2. Como trocar dados com o servidor. Trocar dados entre o Pocket PC e o servidor pode ser implementado de maneira
distinta dependendo de qual camada de comunicação do Pocket PC com a camada do servidor. A figura 1 ilustra três
camadas em tanto no Pocket PC como no servidor.
Figura 1. Camada de aplicação no dispositivo x servidor
As opções de troca de dados para o .NET Compact Framework são:
• Banco de dados no Pocket PC para o Servidor: O banco de dados no Pocket PC troca dados diretamente com o banco
de dados no servidor. Esta opção é válida em cenários com um pequeno ou sem lógica de negócio envolvida, e em
cenários com um grande volume de dados, é implementada usando características Remote Data Access e Merge
Replication do SQL Server CE. Se a sincronização de dados é solicitada e não somente transferência de dados, então o
Merge Replicacion fornece com um construtor a resolução de conflitos implementadas no lado do servidor SQL Server
Reconciler.
• Pocket PC Component para Server Component: A aplicação Pocket PC comunica com componentes no servidor. Esta
opção permite lógica de negócio, implementada em Web services , para ser parte da troca de dados. Esta opção pode
ser usada tanto para persistir dados locais em arquivos XML como no banco de dados SQL Server CE.
• Componente no Pocket PC para o banco de dados no servidor: O Pocket PC conecta diretamente com o banco de
dados do servidor. Esta opção é freqüentemente usada quando a aplicação Pocket PC necessita para gerenciar uma
grande quantidade de dados em um banco de dados remoto sem necessariamente ter que transferir os dados para o
Pocket PC e quando a lógica de negócio não é uma preocupação primária. Esta opção será implementada usando o
namespace System.Data.SqlClient e pode ser usada em ambos se os dados serão persistidos no arquivo XML local e no
banco de dados SQL Server CE.
• Somente no servidor: A interface da aplicação no Pocket PC pode conectar diretamente para o componente no lado do
servidor ou pode ser implementado como uma aplicação WEB utilizando o Web Browser do Pocket PC. Isto obviamente
requer o Pocket PC estar sempre conectado com o servidor, assim como suficiente largura de banda. Um exemplo de
quando isto é uma opção viável é num cenário geograficamente limitado onde uma rede WiFi pode ser implementada

como nas warehouses, instituições de saúde, escritórios e outros. Esta opção não requer nenhum dado a ser armazenado
localmente no Pocket PC.
Tem algumas condições básicas a ser conhecidas ou estabelecidas antes de determinar de que modo dirigir os dois
aspectos “Como armazenar dados” e “Como trocar dados”: Características dos dados, Conectividade e Arquitetura do
Sistema.
Características de Dados
A característica de dados da solução revela as seguintes informações chaves:
1. Quantidade de dados estáticos e transacionais a serem armazenados no Pocket PC: Se a quantidade de dados a ser
armazenada no Pocket PC é baixa, neste caso menor que 50 – 100 kb, então, os dados podem ser armazenados em
arquivo XML locais. Se a quantidade de dados é grande, então, SQL Server CE fornecerá melhor performance e robustes.
A razão disto é que os dados acessados com o SQL Server CE Query Engine com suporte para Structure Query Language
(SQL) que produz maior performance e manuseio.
2. Quantidade de dados transacionais a serem trocados com o servidor: Se a quantidade de dados transacionais a serem
trocados entre o servidor e Pocket PC é baixa, por exemplo, menor que 500 kb – 1 Mb, então, os dados podem ser
passados como XML usando Web Services. Se a quantidade de dados é grande, então, Remote Data Access e Merge
Replication é a primeira opção para melhorar a performance. As razões para isto são que o SQL Server CE Client e Server
Agents implementa uma eficiente compressão de dados e que os dados pegam para transmitir um significante número
menor de processos antes de atingir o destino final. Por exemplo, quando transferir dados do Pocket PC para o servidor
usando Remote Data Access, os dados não possuem as camadas do OLEDB CE, CLR/NET CF, SQL Server CE Data
Provider,e ADO.NET no Pocket PC, assim como no servidor equivale uma vez que transferidos para o servidor.
É importante notar que enquanto isto é criado para usar Web Services para troca de dados, se os dados estão
armazenados em arquivos XML locais, é também possível usar Web Service se os dados estão armazenados no SQL
Server CE – especialmente no Remote Data Access e Merge Replication. A razão disto inclui a lógica de negócios e a
política de arquitetura de sistema existente a ser empregada
Conectividade
O aspecto de conectividade da solução relaciona-se ao tamanho de banda disponível quando e o quanto o Pocket PC
ficará online. Estes fatores podem as vezes estar determinado como pré-requisitos e as vezes estarem definidos e
controlados.
Devido a natureza do XML, no qual muitas vezes guarda grandes quantidades de dados sem compressão, Web Services
requer mais largura de banda para o mesmo dado que SQL Server CE Remote, Data Access e Merge Replication.
Entretanto, a realidade mostra que isto é característica conjunta do Remote Data Access e Merge Replication, que é
chamado para quando grandes quantidades de dados precisam ser trocadas. Além disto, estes dois métodos são
freqüentemente usados quando a troca de dados é baixa, no qual a probabilidade de crescimento da quantidade de
dados que precisa ser trocada é grande. Isto significa que, na realidade, SQL Server CE Remote Data Access e Merge
Replication é usado freqüentemente em cenários de alta largura de banda e Web Services em cenários de baixa largura
de banda. Entretanto, quando usar Web Services, um maior desenho conversador (muitas pequenas requisições) é
preferido antes de um desenho volumoso (poucas grandes requisições).
Arquitetura do Sistema
Aspectos de arquitetura de sistema divide geralmente com assunto de integração de sistemas. Uma solução móvel pode
ser respeitada como uma solução isolada conectando com sistemas existentes ou extensões, parte central do sistema
existente. Sem levar em consideração, soluções Pocket PC não são muito freqüentemente isoladas desde então, elas
precisam se comunicar com outros sistemas.
Atualmente, muitos sistemas são implementados em relação a interface técnica induzindo soluções multi-camadas.
Aplicações do lado do servidor são componentizadas em ordem para permitir o reuso de código, separando a lógica de
negócio e dados, e para aumentar a administração. O uso de XML e Web Services continua induzindo os
desenvolvimentos e as aplicações .NET Compact Framework certamente compatíveis dentro da arquitetura porque
suporta XML e o consume de Web Services.

Outras duas comuns integrações de sistemas implementadas são Asynchronous Messaging (transferência de mensagens)
utilizando consultas e integração com o banco de dados. As aplicações .NET Compact Framework podem aderir para
estas implementações usando Web Service para a fila do servidor MSMQ ou através do uso de Web Services entre
Pocket C e o servidor e usar as filas entre o servidor e o sistema back-office. Bancos de dados integrados é uma parte
natural do SQL Server CE como já discutido.
Códigos
Vamos criar um exemplo simples de código que mostra como implementar as opções mencionadas acima. O código
fonte está em uma simples aplicação chamada Feedback Anyplace, o qual foi usada no WebCast chamado Architect
Webcast: Designing Integrated Pocket PC Applications with .NET Compact Framework e ilustra como um inspetor de
qualidade pode usar o Pocket PC para capturar e relatar defeitos em um cenário de produção. O exemplo requer o
controle RickInk do IntelliProg para trabalhar. Você pode fazer download do código fonte, o qual inclui a aplicação .NET
Compact Framework, Web Services e componentes de banco de dados. O projeto é um exemplo de transferência de
dados, não sincronização de dados.
Armazenando Dados no Pocket PC
O seguinte código mostra como persistir uma propriedade como Class no DataSet e arquivo XML local.
Public Sub Save()
' Save new or update existing item
' Dim ds as DataSet
Dim dr As DataRow
Dim expr As String = "ID = '" + m_ID + "'"
If m_NewItem Then
' Add new row to table
dr = frmMain.ds.Tables("Feedback").NewRow()
Else
' Find existing row
' Use the Select method to find row matching the filter
dr = frmMain.ds.Tables("Feedback").Select(expr)(0)
End If
' Set datarow properties
dr("ID") = m_ID
dr("PlantSection") = m_PlantSection
dr("Part") = m_Part
dr("DefectScope") = m_DefectScope
dr("ScopeID") = m_ScopeID
dr("DefectType") = m_DefectType
dr("RichInk") = m_RichInk If m_NewItem Then
' Add row to dataset, if new item
frmMain.ds.Tables("Feedback").Rows.Add(dr)
End If
' Save data
frmMain.ds.AcceptChanges()
frmMain.ds.WriteXml(frmMain.dataSource)
End Sub
Trocando Dados com o Servidor
A figura abaixo mostra a troca de dados usando Web Services. Em uma solução corporativa, é comum usar uma
plataforma de integração como BizTalk Server.

Figura 2. XML Web Service trocando dados
O cliente do Pocket PC solicita o Web Service no servidor e passa o DataSet (ds) como dados:
Private Sub Synchronize()
Dim username As String = "JohnS"
Dim blnSuccess As Boolean
' Synchronize using XML Web Service
Cursor.Current = Cursors.WaitCursor
Dim wsFeedback As New wsFeedback.feedback
blnSuccess = wsFeedback.InsertFeedback(ds, username)
Cursor.Current = Cursors.Default
End Sub
O Web Service aceita o DataSet e passa o XML diretamente para Stored Procedure do SQL Server 2000, o qual usa
SQLXML e OPENXML para analisar o XML e inserir o novo dados na tabela apropriada.
< WebMethod()> _
Public Function InsertFeedback(ByVal ds As DataSet, ByVal username As String) As Boolean
Dim con As New SqlConnection(connectionstring)
Dim cmd As New SqlCommand("p_Feedback_i", con)
cmd.CommandType = CommandType.StoredProcedure
' Set parameters
Dim prmXML As SqlParameter = cmd.Parameters.Add("@XML", SqlDbType.NText)
prmXML.Direction = ParameterDirection.Input
prmXML.Value = ds.GetXml
Dim prmUsername As SqlParameter = cmd.Parameters.Add("@Username", SqlDbType.NVarChar)
prmUsername.Direction = ParameterDirection.Input
prmUsername.Value = username
Try
con.Open()
cmd.ExecuteNonQuery()
Catch ex As Exception
' Handle, log and re-throw error
Throw ex
Finally
con.Close()
End Try
Return True
End Function
The stored procedure inserts the new data:
CREATE PROCEDURE p_Feedback_i
@XML ntext,
@Username nvarchar(50)
AS
SET NOCOUNT ON
DECLARE @iDoc integer
DECLARE @Error integer
/* Create XML document. */

EXEC sp_xml_preparedocument @iDoc OUTPUT, @XML
/* Insert new records */
INSERT INTO Feedback
(
FeedbackID,
PlantSection,
Part,
DefectScope,
ScopeID,
DefectType,
RichInk,
Username
)
SELECT ID,
PlantSection,
Part,
DefectScope,
ScopeID,
DefectType,
RichInk,
@Username
FROM OPENXML (@iDoc, '/DataSet/Feedback',2) WITH
(
ID uniqueidentifier,
PlantSection int,
Part int,
DefectScope int,
ScopeID nvarchar(50),
DefectType int,
RichInk nvarchar(50)
)
SELECT @Error = @@ERROR
IF (@Error <> 0)
BEGIN
GOTO Errorhandler
END
/* Remove the XML document*/
EXEC sp_xml_removedocument @iDoc
RETURN
Errorhandler:
IF NOT @iDoc IS NULL
EXEC sp_xml_removedocument @iDoc
RAISERROR (@Error,16,1)
RETURN
A figura seguinte mostra troca de dados no SQL Server CE Remote Data Access e Merge Replication.
Figura 3. Troca de dados no banco de dados

Conclusão
Entendendo as características de dados, conectividade e arquitetura do sistema é preciso para determinar uma estratégia
de acesso a dados apropriada. É importante notar que uma solução Pocket PC pode ser oferecida através de um número
de diferentes cenários e situações. Entretanto, é completamente possível que uma estratégia de acesso a dados possa
definir o uso tanto de arquivos XML locais, banco de dados SQL Server CE, Web Services e SQL Server CE Remote Data
Access e Merge Replication dependendo da situação e características atuais.
O .NET Compact Framework deixa projetistas de sistemas e desenvolvedores escolher o método apropriado de acesso a
dados dependendo no número de diferentes cenários. Com uma estratégia de acesso a dados definidos e novas
ferramentas, é fácil ficar focado nos benefícios e projeto das soluções atuais.
Renato Haddad
rehaddad@msn.com
Microsoft Most Valuable Professional
Autor de diversos livros e ministra palestras e treinamentos sobre a tecnologia .NET.
Autor de diversos treinamentos multimídia de ASP.NET e Visual Studio .NET 2003.
Referências:
http://www.microsoft.com/windowsmobile/products/pocketpc/default.mspx
http://www.gotdotnet.com
http://www.smartdevelopers.microsoftdev.com
http://www.microsoft.com/windowsmobile/information/businesssolutions/wifi/default.mspx
http://msdn.microsoft.com/library/default.asp?url=/library/en-
us/guide_ppc/htm/_ppc_writing_applications_for_pocket_pc_uwxf.asp
Faça o download deste documento:
Estratégia de acesso a dados para o Microsoft .NET Compact Framework
formato Word, 111 KB
Inicio da pagina
© 2018 Microsoft

Net framework

Mais conteúdo relacionado

Semelhante a Net framework

Mais de Waldir Calazans

Net framework