Você está na página 1de 70

. Tecnologia NET Guia para Negócios Aplicações

Profis

sional

Cesar de la Torre David Carmona

PUBLICADO POR Microsoft Press Uma divisão da Microsoft Corporation One Microsoft Way Redmond, Washington 98052-6399

Copyright © 2013 Microsoft Corporation

Todos os direitos reservados. Nenhuma parte do conteúdo deste livro pode ser reproduzida ou transmitida de qualquer forma ou por qualquer meio sem a escrita permissão do editor.

Este documento é fornecido apenas para e Microsoft não oferece garantias, expressas ou implícitas, neste documento para fins informativos. As informações contidas neste documento, incluindo URLs e outras referências a sites da Internet, estão sujeitas a alterações sem aviso prévio. Todo o risco do uso ou os resultados do uso deste documento permanece com o usuário.

Salvo disposição em contrário, as empresas, organizações, produtos, nomes de domínio, endereços de email, logotipos, pessoas, lugares e eventos descritos em exemplos são fictícios. Nenhuma associação com qualquer empresa, organização, produto, nome de domínio, endereço de e-mail, logotipo, pessoa, lugar ou evento é intencional ou deve ser inferida.

Microsoft e as marcas listadas no http://www.microsoft.com/about/legal/en/us/IntellectualProperty/Trademarks/EN-US.aspx são marcas comerciais da o grupo de empresas Microsoft. Todas as outras marcas são de propriedade de seus respectivos proprietários.

Este livro expressa pontos de vista e opiniões do autor. As informações contidas neste livro é fornecido sem qualquer expressa, legal, ou implícita garantias. Nem os autores, Microsoft Corporation, nem seus revendedores ou distribuidores serão responsabilizados por qualquer dano causado ou alegadamente causados direta ou indiretamente por este livro.

Capa: Toque criativo • Seattle e Joel Panchot

Conteúdo

1. Chave takeaways 4 2. Finalidade deste guia 4 QUEM DEVE USAR ESTE GUIDE COMO
1. Chave takeaways
4
2. Finalidade deste guia
4
QUEM DEVE USAR ESTE GUIDE
COMO USAR ESTE GUIA
4
5
3. Visão global
5
O. NET Framework. EO FUTURO DO DESENVOLVIMENTO
6
4. Emergentes padrões de aplicativos
9
DEVICES
As aplicações nativas para dispositivos Windows
10
11
Aplicações Web para qualquer device
12
SERVIÇOS
NUVEM E HYBRID-CLOUD
CENÁRIOS END-TO-END nos países emergentes padrões de aplicativos
Cenário: Conectado nativo do Windows loja de aplicativos
Cenário: Aplicações Web modernos para qualquer dispositivo móvel (comprimidos e telefone)
14
16
19
19
5. Padrões21
de aplicativos estabelecidos
23
Aplicações de negócio SEGMENTAÇÃO POR PRIORIDADES
APLICAÇÕES empresa de pequeno porte e médias
Negócio na web Data-centric applications
23
25
27
Cenário: End-to-End Small / Medium Business Applications Web
Abordagem mista para aplicações de pequenas / médias empresas web
28
29
Aplicações de negócios dados desktop-centric
Cenário: Small / Medium 2-Tier Desktop Application
Cenário: Small / Medium 3-Tier Aplicativos Desktop
Modernizar a aplicativos de negócios de desktop
30
31
32
33
Modernizar aplicações baseadas em RIA containers
CLOUD APP MODELO PARA Office e SharePoint
Apps para o
Office
Cenário: Conectado Apps para o Office
Apps para o SharePoint
34
35
35
39
40
Cenário: Conectado Apps para o SharePoint
GRANDES, aplicações de negócio MISSÃO CRÍTICA
. NET em aplicações de missão crítica e core-business grandes
Seleção de Tecnologia para grandes aplicações de missão crítica e core-business
Cenário: grandes, aplicações core-business
Abordagens e tendências para aplicações de core-comerciais de longo prazo
43
44
44
45
46
50
Arquitetura de baixo acoplamento e do princípio da dependência inversão
Estilos de arquitectura para aplicações de core-business
Modernizar aplicações corporativas de missão crítica
Cenários para aplicações personalizadas grandes de missão crítica
50
53
55
55
Cenário: Subsistema de Domain-Driven (Contexto Delimitada)
Cenário: CQRS Subsystem (Contexto Delimitada)
Cenário: Comunicação Diferente Limitada Contexts
55
60
62

Cenário: Aplicações Modernização Legado de Missão Crítica empresa

63

6. Conclusões

Apêndice A: caminhos de migração do Silverlight

Apêndice B: tecnologias de acesso a dados de posicionamento

65

66

68

1.

Delivery chave

Selecione suas abordagens de arquitetura e tecnologia de desenvolvimento com base nas prioridades de sua aplicação específica e requisitos.

A arquitetura única e uma abordagem não vai funcionar para todos os tipos de aplicação. A pilha de desenvolvimento Microsoft e. NET são

extremamente flexível e oferecem muitas possibilidades, mas é essencial que você escolha abordagens e tecnologias específicas com base em

o tipo de aplicação ou mesmo subsistema-lo a construir. Cada aplicação terá muito diferentes prioridades e compromissos que devem

ser levado em caminhos diferentes.

Modernização de aplicações de negócios vai além da simples criação de aplicativos móveis. As aplicações móveis devem confiar e estender seus aplicativos de negócios fundamentais.

Para ser bem sucedido, aplicativos móveis deve ser construído com integração profunda em seus aplicativos de negócios fundamentais atuais. Móvel

aplicativos de negócios deve ser parte do maior ecossistema empresarial e substancialmente estender aplicações de negócio fundamentais,

aplicações legadas se os sistemas fundamentais são estabelecidas ou novas aplicações de missão crítica, grandes, construídos com

serviços inovadores, escaláveis e elásticos.

Posicionando o aplicativo ou subsistema dentro de uma segmentação de padrões globais vai ajudar você a escolher o abordagens e tecnologias certas.

É fundamental para posicionar sua aplicação / subsistema na área de segmentação direita. As abordagens e tecnologias certas

para cada um dos seguintes tipos de aplicações pode ser potencialmente muito diferente:

Emergentes padrões de aplicativos

- Dispositivos e serviços

Padrões de aplicativos estabelecidos

- aplicativos de negócios de pequenas e médias

- Grandes, aplicativos de negócios de missão crítica

2. Finalidade deste guia

Este guia irá ajudá-lo efetivamente selecionar as tecnologias adequadas de desenvolvimento da Microsoft e abordagens para o seu. NET personalizado

desenvolvimento de aplicações, de acordo com as prioridades que você tem para o seu pedido e para o seu domínio do negócio.

Esta orientação não cobre práticas de Gestão do Ciclo de Vida de Aplicações (ALM). Para obter orientação adicional sobre este assunto, você pode

visite o site do Visual Studio ALM em www.microsoft.com / VisualStudio / alm.

Quem deve usar este guia

Este guia será útil para os decisores, arquitetos de software, líderes de desenvolvimento e os desenvolvedores que estão envolvidos na escolha

as tecnologias a utilizar para seus aplicativos e projetos baseados em plataformas de desenvolvimento da Microsoft.

Especificamente, ele abrange o desenvolvimento de aplicações corporativas personalizadas, embora ISVs também pode encontrar as informações e

ções recomen- úteis.

Este artigo não cobre soluções de desenvolvimento baseadas em produtos Microsoft para o mercado de negócios, tais como soluções verticais

em baseados Dynamics CRM ou ERP Dynamics.

Como usar este guia

Este guia abrange um amplo espectro de opções de desenvolvimento de software com foco em aplicações de negócios. É escrito como uma referência

documento para que você pode ir diretamente para uma área que você está interessado, como a Seção 4, "emergentes padrões de aplicativo", ou

aplicativos "Grande, de negócios de missão crítica "dentro Seção 5," Estabelecido padrões de aplicativos. "

Nós recomendamos que você leia Seção 3, "Visão geral" para o contexto antes de mergulhar mais fundo nas seções individuais.

3. Visão global

Hoje, o uso da tecnologia está no meio de uma mudança em direção a experiências multi-dispositivo alimentado por serviços na nuvem. Padrões de

estão uso cada vez mais dependentes de recursos de hardware locais, tais como toque, sensores e mobilidade, combinados com o poder da web

serviços de conectividade e back-end, tais como armazenamento de dados, streaming de mídia e conectividade social.

O nexo dispositivos de serviços abrange ambos os cenários de negócios e de consumo. No espaço do consumidor, a computação móvel inicialmente

uma criado onda de dispositivos focados em consumo, que continua a crescer à medida que recursos e tecnologias de hardware antecedência. Dentro

a empresa, os fenômenos gêmeos da consumerização de TI e trazer-seu-próprio-dispositivo (BYOD) criaram uma dinâmica

que experiências de consumo estão impulsionando o futuro da computação empresarial e de linha de negócios (LOB).

A próxima geração de aplicações dependentes de serviços do dispositivo e não está a emergir de forma isolada. Estas aplicações têm de trabalhar

de forma extremamente bem integrado com aplicações existentes, libertar o seu valor a novos públicos e novos modos de

interação. Como mostrado na Figura 3-1, isso cria dois padrões diferentes que cada desenvolvedor do aplicativo deve agora enfrentar:

Padrões de aplicativos Estabelecida: Estas são aplicações desenvolvidas usando padrões de tecnologia, tais como cliente / servidor ou

aplicações web otimizado para navegadores desktop. Eles agem como aplicações fundamentais e são fortemente centrada na existente

processos de negócio.

Emergentes padrões de aplicativos: Padrões como o multi-dispositivos ea nuvem estão emergindo como facilitadores de tecnologia para

novas aplicações. Eles complementam os padrões estabelecidos, estendendo os aplicativos a serem centradas no o usuário final.

Padrões de aplicativos Evolução

Figura 3-1

Esta extensão de padrões estabelecidos para atender o usuário final é uma oportunidade chave para os desenvolvedores para conduzir inovação e

concorrentes vs diferenciação. Varejo, comunicações, finanças, logística, serviços de cada cliente empresa é um software

empresa no mundo empresarial de hoje. Capacidade de cada empresa para satisfazer as necessidades dos clientes e competir de forma eficaz é

sua apenas capacidade tão bom de quanto fornecer inovação de software.

No entanto, a extensão de aplicativos existentes para abraçar estas novas necessidades é um processo de transformação desafiador. Atual

tecnologias de desenvolvimento estão profundamente enraizados no padrão estabelecido e são difíceis de integrar com os padrões emergentes

necessário para software moderno. As ferramentas existentes não fornecem um caminho óbvio do mundo cliente / servidor existente para o

mundo emergente dispositivo / cloud.

A plataforma Microsoft permite que os desenvolvedores para enfrentar esses desafios. Baseia-se aplicações existentes, estendê-los para

padrões de aplicativos emergentes. Ela abraça múltiplas tecnologias de desenvolvimento, para que os desenvolvedores podem escolher a opção que

se melhor adapta às suas habilidades ou as tecnologias utilizadas por seus aplicativos existentes. Para o desenvolvimento de serviços, Microsoft Windows

uma Azure infinidade suporta de tecnologias que qualquer desenvolvedor pode usar, como Java, Node.js, PHP, Python, Ruby, e suporte de primeira classe para. NET.

Desenvolvimento do cliente para a plataforma Microsoft também suporta uma ampla gama de tecnologias de forma nativa, como. NET,

HTML5/JavaScript, e C + +.

Este documento concentra-se em. NET desenvolvimento e, especificamente, em aplicações de negócios. Abrange como usar. NET desenvolver para

os padrões estabelecidos que moldam as aplicações existentes e também como abraçar os padrões emergentes que estão permitindo a

aplicativos de negócios modernos do futuro, ver Figura 3-2.

Aplicações de Negócio modernos

Figura 3-2

O NET Framework. Eo futuro do desenvolvimento

A Microsoft. NET Framework foi construído para permitir que os desenvolvedores criem aplicativos interessantes sobre a plataforma Microsoft e,

por todas as contas, foi um enorme sucesso no mercado. Hoje, milhões de desenvolvedores em todo empresas de todos os portes e segmentos

confiar. NET para criar aplicações. Ele fornece os serviços básicos necessários para construir aplicações de consumo; pequena empresa

aplicações, e aplicações de missão crítica de grandes, todos com qualidade sem precedentes, desempenho e produtividade.

. NET também foi construída com estes padrões, agora emergentes em mente. No Forum 2000, Bill Gates, disse que a meta para. NET era "para mover

além do mundo de hoje de sites independentes para uma Internet de componentes intercambiáveis, onde dispositivos e serviços podem ser

montadas em experiências orientadas para o utilizador coesas. "A visão original. NET está muito bem alinhado com a desenvolvedora de hoje

paisagem, incluindo cross-dispositivo, experiências movido a serviços que estão mudando a forma como a indústria pensa em software

desenvolvimento.

Ativando experiências multi-dispositivos habilitados por serviços era um atributo fundamental para. NET desde o

desde então, oferecendo uma experiência de desenvolvimento de primeira classe para as novas necessidades de aplicações:

NET manteve em evolução

No lado do servidor, . NET fornece uma plataforma comum para os desenvolvedores para direcionar serviços que são executados no local ou

no nuvem. Sua estreita integração com o Windows Server e Windows Azure permite que aplicativos sejam gradualmente estendido para o

nuvem, tendo o melhor de cada plataforma e permitindo aplicações híbridas que ficam entre os dois mundos. A entrega rápida

cadência nas bibliotecas. NET Framework também fornece inovação contínua que aborda as novas necessidades de cloud-based

aplicações em áreas como serviços leves, comunicações em tempo real, aplicações web móveis e autenticação.

No lado do cliente, . NET oferece uma experiência de desenvolvimento consistente de primeira classe em todos os dispositivos da Microsoft:

área experiências, de trabalho aplicativos do Windows Phone e do Windows loja de aplicativos (como mostrado na Figura 3-3). Ele permite. NET para manter

desenvolvimento de aplicações fundamentais na área de trabalho e adicionar novas experiências emocionantes, tudo ao mesmo tempo

e usando reutilização suas habilidades de código entre existentes os dispositivos. Em cenários onde o alcance vai além de dispositivos da Microsoft, baseado em navegador

HTML5

soluções são a

aplicações web que rodam em vários dispositivos. Para desenvolvedores que querem criar mais adaptadas, experiências nativas em qualquer

dispositivo, parceiros da indústria Visual Studio fornecer soluções que permitem a reutilização de C # habilidades e código com dispositivos não-Windows.

NET, em conjunto com o Visual Studio, fornece uma solução moderna para a criação baseada em padrões

. NET em que o servidor está dissociado do lado do cliente

Figura 3-3

Este documento aborda todas essas opções. NET desenvolvimento para que você possa tomar a decisão certa para suas habilidades atuais e

requisitos de aplicação que você mover suas aplicações para a frente. Ele está estruturado para abordar os dois padrões de aplicativos:

"emergentes padrões de aplicativo" se concentra em como construir aplicativos usando os padrões emergentes que estão moldando o

novas aplicações em dispositivos e serviços. "Padrões de aplicativos estabelecida" abrange as tecnologias disponíveis para a criação de aplicativos de negócios fundamentais, como bem como recomendações sobre como modernizá-las.

Figura 3-4 mostra um diagrama global de tecnologias de plataforma de desenvolvimento da Microsoft. As próximas seções recomendar quando a

utilizar tecnologias que, dependendo dos padrões e as prioridades de utilização.

Microsoft Development Platform Technologies

Figura 3-4

4. Emergentes padrões de aplicativos

Como mencionado antes, padrões de aplicativos emergentes estão moldando as aplicações do futuro. Clientes e funcionários agora

aplicações de demanda que proporcionam uma experiência mais pessoal. Eles querem ficar continuamente conectado aos serviços de que necessitam.

Esta seção está estruturada pelos dois esforços principais que precisam ser abordadas ao desenvolver essa nova geração de aplicações:

Criando experiências através de dispositivos heterogêneos.

Criando, serviços leves padrão que se estendem através da nuvem.

Os padrões de aplicativos emergentes são, em muitos aspectos, comparáveis aos de "sistemas de engajamento" (termo originalmente cunhado por

Geoffrey Moore e também freqüentemente usado por Forrester, como mostrado na Figura 4-1), mas, adicionalmente, que deve ser suportado pela

nuvem e deve confiar e estender real

"sistemas de registro" (ie, negócios fundacional

aplicações).

"Sistemas de engajamento" não significa apenas

"aplicações que visam apenas os consumidores." Na verdade,

há muitos novos cenários na empresa

(Tais como aplicativos internos com necessidades de mobilidade

como dashboards), juntamente com cenários de segmentação

clientes finais (tais como serviços bancários on-line e

e-commerce), onde este conceito é perfeitamente válido.

Figura 4-1

Portanto,

padrões de aplicativo inclui a necessidade de serviços contínuos e elásticas, além de necessidades móveis e direct-to-consumer

ligação, como mostrado na Figura 4-2.

Da Microsoft

visão

de

emergente

Na maioria das aplicações empresariais modernas, o aplicativo cliente vai precisar de um serviço remoto, a fim de trabalhar com os dados e fornecer um

Emergentes Padrões de aplicativos

orquestração centralizado. Este é o lugar onde você precisa de orientação a serviços

baseado em padrões da Internet para serviços remotos. Finalmente, estes

serviços serão implantados na infraestrutura de nuvem pública e

serviços, que são os pilares para os padrões emergentes em relação ao

ambientes de implantação.

Figura 4-2

À medida que perfurar mais para os padrões de aplicativos emergentes, você vai

para precisar ter em conta todos os possíveis dispositivos móveis e sociais

redes como um meio para estender seus aplicativos de negócios para um novo

casos de uso e para a construção, os serviços contínuos sólidos que podem flexivelmente dimensionado para atender qualquer demanda, ver Figura 4-3.

Dispositivos, sociais, serviços, dados e nuvem

Dispositivos

Figura 4-3

A capacidade de oferecer novas experiências personalizadas para dispositivos é o atributo chave para os padrões de aplicativos emergentes.

tecnologia Escolhendo para o criar esses aplicativos pode ser difícil e envolve muitos fatores, incluindo:

Suas habilidades anteriores e preferência de tecnologia.

A capacidade de criar experiências personalizadas que se integram com os recursos de hardware local.

A diversidade de dispositivos de sua aplicação terá como alvo.

A tecnologia usada por seus aplicativos existentes que

Cenários para Dispositivos e Tecnologias Microsoft

precisam ser migrados ou estendido para dispositivos.

As duas alternativas comumente estabelecidos na indústria são

com base em diferentes abordagens:

As aplicações nativas, que possa tirar o máximo de cada

dispositivo, mas exigem habilidades únicas e código para cada

Aplicações plataforma. Web, que pode ser criado com um comum

conjunto de competências e de código, mas que não pode fornecer uma

experiência adaptada para cada dispositivo.

A plataforma Microsoft apoia plenamente ambas as abordagens (ver Figura

4-4), mas reduz as desvantagens de cada um de forma significativa. Primeiro,

Dispositivos Windows não impõem um desenvolvimento único nativo

modelo. Você pode usar a tecnologia que faz mais sentido para

suas habilidades e suas aplicações existentes. Ao trazer de primeira classe

integração dispositivo. NET, HTML / JavaScript e C + +, você pode

tomar a decisão que melhor se adapta às suas necessidades sem comprometer

a experiência. Em segundo lugar,. NET e Visual Studio simplificar

criação de aplicações web que podem ser executados em qualquer dispositivo. ASP.NET abraça plenamente os padrões modernos e, em conjunto com

as últimas inovações únicas no Visual Studio, permite que uma nova geração de aplicações web que tira o máximo partido da moderna

navegadores através de dispositivos.

Figura 4-4

As aplicações nativas para dispositivos Windows

Um aplicativo nativo é um aplicativo que é executado no cliente dispositivo e tira o máximo proveito dos recursos específicos desse dispositivo

a fim de proporcionar a experiência mais atraente para

clientes. Como explicado anteriormente, a plataforma Windows se estende este conceito para além de tecnologias C + +, que expande enormemente

o potencial de reutilização de seu código e habilidades para atingir nova forma fatores.

Quadro 4-1 e Quadro 4-2 explicar as diferenças entre estes tecnologias e quando eles são apropriados para usar, dependendo em suas prioridades de aplicação e contexto concreto.

Native Windows Store e Windows Phone Apps

Figura 4-5

Tecnologias de desenvolvimento de interface do usuário para nativo Aplicações da Windows Store (Windows Runtime [WinRT])

Technologies

NET / XAML

JavaScript /

HTML5

Quando usar e por quê

Apropriada, se você já está familiarizado. NET e XAML ou ao estender NET / XAML existente aplicações. Ele também permite que você compartilhe. NET Framework e bibliotecas entre o Windows loja de aplicativos, o Windows Aplicativos do telefone, aplicativos de desktop do Windows e outras plataformas da Microsoft, utilizando bibliotecas de classes portáteis. Aproveite open source. Bibliotecas NET como sqlite-net para bancos de dados SQL locais luz, ou SignalR. NET cliente para comunicação bidirecional entre o cliente eo servidor.

Apropriada, se você já está familiarizado com as tecnologias HTML e JavaScript ou você está criando um Windows Store adaptados experiência para sua aplicação web existente. Ele permite que você reutilize costume JavaScript ou ativos HTML / CSS de aplicações web baseadas em navegador existentes e usar a nova biblioteca WinJS para obter acesso aos recursos nativos do Windows Store apps / API. Aproveite bibliotecas JavaScript de código aberto, como SQLite3-WinRT para banco de dados SQL local luz motores, ou cliente SignalR JavaScript para comunicação bidirecional entre o cliente eo servidor.

C + +

Apropriada, se você já está familiarizado com C + +. Ele permite que você otimizar e alcançar o melhor desempenho para gráficos intensivos aplicativos ou jogos. Esta opção também permite que você compartilhe o código C + + entre o Windows, o Windows Phone, e outras plataformas, como bem como Direct3D alvo para acesso gráficos de baixo nível. Aproveite open source código C / C + +, como SQLite.

Tabela 4-1

Referências

Maximizar a reutilização de código entre Windows Phone 8 e Windows 8

http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681693

Prism for Windows Runtime de Microsoft Patterns & Practices

ASP.NET SignalR: incrivelmente simples web em tempo real para. NET

SQLite: System.Data.SQLite

Visual C + + e WinRT: Some fundamentos

http://prismwindowsruntime.codeplex.com/

http://signalr.net/

http://system.data sqlite.org / index.html / doc / trunk / www / downloads.wiki

http://www.codeproject.com/Articles/262151/Visual-Cplusplus-and-WinRT-Metro-Some-

fundamentos

Tecnologias de desenvolvimento de interface do usuário para nativo Windows Phone 8 aplicações

Quando usar e por quê

Technologies

NET / XAML

C + +

Apropriada, se você já está familiarizado. NET e XAML ou você está estendendo NET / XAML existente aplicações. Ele permite que você compartilhe. NET Framework e bibliotecas entre Windows Phone, o Windows Store, Do Windows desktop, e outras plataformas da Microsoft, utilizando bibliotecas de classes portáteis. Aproveite open source. Bibliotecas NET, como sqlite-net-wp8.

Apropriada, se você já está familiarizado com C + +. Ele permite que você otimizar e alcançar o melhor desempenho para gráficos intensivos aplicativos ou jogos. Esta opção também permite que você compartilhe o código C + + entre Windows Phone, o Windows Store, e outros plataformas, bem como Direct3D alvo para acesso gráficos de baixo nível nessas plataformas. Aproveite open source código C / C + +, como o SQLite.

Tabela 4-2

Referências

Windows Phone 8 desenvolvedor destaques da plataforma

Windows Phone 8 e Windows 8 desenvolvimento de aplicativos

Maximizar a reutilização de código entre Windows Phone 8 e Windows 8

Desenvolvimento de aplicativos Direct3D para Windows Phone 8

http://blogs.windows.com/windows_phone/b/wpdev/archive/2012/11/05/windows-

telefone-8-desenvolvedor-platform-highlights.aspx

http://msdn.microsoft.com/en-

us/library/windowsphone/develop/jj714089 (v = vs.105). aspx

http://msdn.microsoft.com/en-us/library/windowsphone/develop/jj681693

http://msdn.microsoft.com/en-

US/library/windowsphone/develop/jj207052 (v = vs.105). Aspx

Aplicações Web para qualquer dispositivo

Microsoft fornece ferramentas e tecnologias de best-of-breed para a criação de aplicativos baseados em navegador HTML5 que rodam em qualquer

A

Como dispositivo. o Windows também suporta HTML5 como uma tecnologia nativa, você pode direcionar vários dispositivos com aplicações web HTML5, então

reutilizar

e

otimizar o código para um aplicativo nativo do Windows Store.

interruptor automático para diferentes renderização de HTML ou o dimensionamento pode ser alcançado através de diferentes mecanismos

O

JavaScript fornecidos e pelo LightSwitch, ASP.NET, bem como bibliotecas como Modernizr, que irá detectar o navegador e adaptar o seu HTML / JavaScript

codificar, como mostrado na Figura 4-6.

Web Apps modernos

Figura 4-6

Esta abordagem é particularmente vantajoso quando o direcionamento diferentes sistemas operacionais (como Windows, iOS, Android e). Depois alcançar compatibilidade com os navegadores mais comuns, a sua candidatura será multi-plataforma compatível com a maior sistemas operacionais móveis.

Tabela 4-3 enumera a amplitude de tecnologias web-desenvolvimento disponíveis e recomenda quando usar cada tecnologia, dependendo de suas prioridades e contexto de aplicação.

Tecnologias de desenvolvimento de interface do usuário para teia aplicações

Technologies

Quando usar e por quê

ASP.NET MVC

com HTML5

apoio

ASP.NET SPA

Cliente para HTML5 LightSwitch projetos

ASP.NET MVC com suporte HTML5 Use para aplicações flexíveis e modernos móveis da web, compatibilidade cross-browser, clientes da web móvel que podem ser executados em qualquer dispositivo moderno, e para tirar proveito dos recursos móveis ASP.NET MVC (como o uso de diferentes páginas e renderização com base na detecção do agente de usuário do navegador atual). Oferece um controle HTML completo de renderização, melhor suporte de testes de unidade e capacidade de fingir. HTML5: Use as bibliotecas como Modernizr para a detecção de HTML5 possui suporte e soluções alternativas. Use CSS3 para menos script e código mais sustentável. Use JavaScript e jQuery para a programação do lado do cliente. MVC permite otimizações do Search Engine (SEO) personalizações. URLs RESTful são uma parte integrante da MVC.

Aplicação Página Única (SPA) baseado em ASP.NET MVC, HTML5/JavaScript, Knockout, e Brisa SPA não é uma estrutura, mas um padrão de projeto que pode ser implementado utilizando ASP.NET MVC e pesado uso de bibliotecas JavaScript como Nocaute (Para apoiar o padrão MVVM dentro de JavaScript) e como o Brisa Biblioteca JavaScript para gestão avançada de dados e frameworks JavaScript como Durandal. Use-o para aplicações web altamente interativas e atualizações de interface do usuário suaves (recarregar a página e servidor mínimo viagens visíveis redondas) e quando incluindo interações significativas do lado do cliente usando HTML5, CSS3, e JavaScript. Aproveite o código-fonte aberto SignalR JavaScript biblioteca cliente para comunicação bi-direcional entre o cliente eo servidor. Consumir serviços API Web ASP.NET a partir de JavaScript.

Cliente LightSwitch HTML5 Utilize se o seu aplicativo web ou módulo é principalmente (CRUD [Criar, Ler, Atualizar e Excluir]) baseado em dados. O cliente LightSwitch HTML5 é a maneira mais fácil de criar-centric de dados, cross-browser, e web móvel aplicações que podem rodar em qualquer dispositivo moderno, tirar proveito de renderização de HTML automático, e adaptar-se a diferentes fatores de forma.

Aproveite CSS3, JavaScript e OSS JavaScript bibliotecas como jQuery Mobile e temas. Acoplado ao motor end-to-end LightSwitch runtime que é construído em cima do ASP.NET.

ASP.NET Páginas da Web

Páginas da Web ASP.NET Páginas da Web ASP.NET ea sintaxe Navalha fornecer uma maneira rápida, acessível, e leve para combinar código do servidor com HTML para criar conteúdo web dinâmico.

Tabela 4-3

Referências

Recursos móveis ASP.NET MVC

ASP.NET SPA (Página Única Aplicação)

Modelo Breeze / Knockout

Quadro Durandal SPA

Biblioteca RequireJS

BootStrap

Modernizr: a detecção de recurso biblioteca para HTML5/CSS3

LightSwitch Arquitetura

Melhore seu LightSwitch Aplicações com OData

Telas de cliente para HTML Apps LightSwitch

http://www.asp.net/mvc/tutorials/mvc-4/aspnet-mvc-4-mobile-features

http://www.asp.net/single-page-application

http://www.asp.net/single-page-application/overview/templates/breezeknockout-template

http://durandaljs.com/

http://requirejs.org/

http://twitter.github.io/bootstrap

http://www.modernizr.com

http://msdn.microsoft.com/en-us/vstudio/gg491708

http://blogs.msdn.com/b/bethmassi/archive/2012/03/06/enhance-your-lightswitch-

aplicações-com-odata aspx

http://msdn.microsoft.com/en-us/library/vstudio/jj674623.aspx

Serviços

O processo de direcionamento de vários dispositivos começa no back-end. Os aplicativos precisam expor serviços que podem ser consumidos em

qualquer dispositivo e escalado para a Internet.

Serviços de Internet está destinado a ter alta disponibilidade e continuidade com os serviços de back-end que permitem aplicações modernas

para trabalhar. Eles também devem ser ágeis e ter uma evolução contínua, suave, aderindo à velocidade das mudanças do negócio.

Dentro desse contexto, o "NET ecossistema." e os quadros são essenciais na construção de serviços.

Como mostrado na Figura 4-7, o NET Framework.

suporta uma ampla gama de abordagens para a construção

aplicações: ASP.NET abordagens para teia

desenvolvimento (aplicação de página única [SPA]

Model-View-Controller [MVC], e WebForms);

API Web ASP.NET para a construção de HTTP / REST

serviços, e usando o Entity Framework para acesso

dados em bancos de dados relacionais. A maioria do lado do servidor desenvolvimento geralmente é baseado em um. NET

tecnologia.

Tabela 4-4 descreve as tecnologias que podem ser usados

construir serviços:

. NET é fundamental para Serviços de Construção

Figura 4-7

Tecnologias de serviços de back-end (Para ser consumido por aplicações nativas ou web)

Technologies

ASP.NET

API Web

Quando usar e por quê

HTTP baseado, a abordagem REST, orientado recurso, o foco em OData e JSON É a tecnologia preferida para o desenvolvimento de serviços flexível com RESTO abordagens OData, ou JSON requisitos. Tente usar API Web como sua primeira escolha quando se avalia qual tecnologia usar. Use qualquer um dos as outras tecnologias se API Web não atender às suas necessidades.

Feito especialmente para os serviços REST. Abraça verbos HTTP (PUT, GET, POST, DELETE

motoristas. Recursos orientada. Alta escalabilidade graças a caches Internet (Akamai, o Windows Azure CDN, Level3, e assim por diante) com base em HTTP

) como a aplicação

verbos.

Windows

Comunicação

Fundação

(WCF)

Dados WCF

Serviços

Fluxo de Trabalho Serviços

SignalR

LightSwitch

OData

Serviços

Dissociar e abordagem flexível Use-o quando você precisa de interoperabilidade SOAP ou você quiser usar um transporte não-HTTP. WCF pode usar qualquer protocolo (como HTTP, TCP, ou pipes nomeados), formatos de dados (tais como SOAP, binário, JSON, ou outros), e os processos de hospedagem. Essa tecnologia funciona melhor para (/ tarefa orientada para comando) serviços RPC-estilo e para a empresa inter- comunicações de aplicativos. REST é possível, mas não preferido aqui. Bom ajuste para usar com o Microsoft Service-Bus (no Windows Azure ou Windows Server) e AppFabric hospedagem e de monitoramento.

Serviços de dados-driven Use-o quando seus serviços são dados / orientada a recursos e principalmente CRUD e data-driven. Suportes OData só. Simples de usar, mas oferece menos flexibilidade e controle do que o uso da Web ASP.NET API. Compartilha o mesmo bibliotecas centrais OData com API Web ASP.NET.

Abordagem baseada em fluxo de trabalho para serviços de construção Utilize se sua lógica de serviço é internamente um fluxo de trabalho do Windows Workflow Foundation (WF). Externamente, este é realmente um serviço WCF. Workflow Services tem todas as vantagens e características do WCF e WF, mas é acoplado a WCF. Biblioteca ASP.NET SignalR Use para a funcionalidade em tempo real no lado do cliente. Essa abordagem permite que o código do lado do servidor para empurrar conteúdo para os clientes conectados em tempo real e em alta escala, até mesmo para milhões de usuários. É HTTP e baseado em WebSockets. Pode ser consumido a partir de JavaScript em clientes de navegador,. NET nativo Clientes Windows e eventos do lado do servidor, e longa votação.

OData e abordagem REST, orientado recurso, maneira fácil de construir serviços baseados em dados Use-o se o seu aplicativo cliente é um aplicativo LightSwitch ou para simples autônomo e serviços OData data-driven. Visualmente modelar seus dados e LightSwitch criará automaticamente os serviços. É baseado em OData. Bibliotecas do cliente consumo Serviços são os mesmos. Acoplado ao motor LightSwitch servidor, OData (Aberto repousante Data Protocol), XML, JSON, e HTTP. Menos flexível que o API Web e WCF, mas não requer nenhuma codificação.

Tabela 4-4

Referências

API Web ASP.NET

WCF

Ferramentas do WCF Data Services para Da Windows Store Apps

Criando e consumindo LightSwitch OData Serviços

ASP.NET SignalR

http://www.asp.net/web-api

http://msdn.microsoft.com/en-us/library/ms731082.aspx

http://www.microsoft.com/en-us/download/details.aspx?id=30714

http://blogs.msdn.com/b/bethmassi/archive/2012/03/09/creating-and-consuming-

lightswitch-odata-Services.aspx

http://signalr.net/

Cloud e híbrido em nuvem

Aplicativos de negócios modernos normalmente suportam muitos Internet

usuários (como os clientes finais e parceiros), de modo que a manutenção de sua

serviços de back-end dentro de datacenters internos da sua empresa pode

não faz sentido. Por esta razão, os serviços são susceptíveis de ser implantado

na nuvem. Os serviços também beneficiar das capacidades fundamentais do

nuvem, como elasticidade e uma produção rápida e eficiente em termos de custo

setup.

Além disso, muitos aplicativos de negócios modernos são o resultado de

novas idéias, novos canais e novas oportunidades. Você nunca sabe

se você vai atrair um número significativo de novos usuários, exigindo, assim,

mais recursos do que o que está disponível em seus datacenters internos.

Novos canais e dispositivos Precisa a elasticidade da nuvem

Figura 4-8

A

nuvem é ágil e escalável, para que possa desenvolver novos conceitos

e

rapidamente movê-los para a produção sem investimentos em hardware ou configurações. Portanto, nuvens plataforma elásticas, como o Windows

Azure, são as melhores opções para aplicativos de negócios modernos.

Em um ecossistema diversificado, onde aplicações de negócios vivem em diferentes ambientes (tanto na nuvem e no local), há

muitas novas necessidades para atender. Porque você também estão estendendo as aplicações fundamentais que estão atualmente no local, é

ligação necessário entre um os centros de dados privados e da nuvem, e você precisa de vincular esses mundos de forma segura através de um híbrido de nuvem

abordagem, como mostrado na Figura 4-9.

Aplicações modernas e híbrido-Cloud

Figura 4-9

A plataforma de nuvem da Microsoft oferece arquitetura simétrica, tecnologias e produtos para apoiar a nuvem e no local

infra-estruturas-e fornece serviços comuns para gerenciar aplicativos que abrangem as duas infra-estruturas in híbrido

ambientes. Esta plataforma permite que você migre e construir suas aplicações com facilidade e de forma gradual.

Como mostrado na Figura 4-10, a Microsoft fornece uma plataforma consistente, se o aplicativo tem como alvo a nuvem ou on-

premissas infra-estrutura. Para as práticas de desenvolvimento, o melhor é usar a mesma plataforma de desenvolvimento (por exemplo, Visual Studio

tanto ou. NET) para ambientes de nuvem e no local. Da mesma forma, ter um sistema único para controlar e gerenciar a infra-estrutura (como

System Center) para qualquer no local ou sistema em nuvem é fundamental para a governança de TI eficiente.

Referências

Microsoft Cloud Pública

Microsoft avança a nuvem OS Soluções com nova gestão

Nuvem Híbrida

Nuvem OS Visão

Uma plataforma consistente

Figura 4-10

http://www.microsoft.com/en-us/server-cloud/public-cloud/default.aspx

http://www.microsoft.com/en-us/news/press/2013/jan13/01-15OSMomentPR.aspx

http://www.microsoft.com/enterprise/en-nz/solutions/hybrid-

cloud.aspx # fbid = CmzuvecYY9J

http://www.microsoft.com/en-us/server-cloud/cloud-os/

Tabela 4-5 expõe as principais tecnologias do Windows Azure relacionados ao desenvolvimento de aplicativos.

Tecnologias de nuvem Windows Azure

Technologies

Quando usar e por quê

Execução

Modelos

Modelos de execução para aplicações web e serviços Windows Azure oferece suporte a vários modelos de execução que você pode escolher, dependendo suas necessidades. Serviços de Infraestrutura (Infrastructure as a Service / IaaS): Use-o quando você precisa de um tradicional e flexível abordagem, onde são responsáveis pela infra-estrutura de máquina virtual interna e software manutenção e administração (sistema operacional, serviços, etc.) Ele suporta instalações tradicionais de software, como completo SQL Server. Sites da Web (Web hosting): Use-o como uma maneira fácil de começar, basta a implantação de aplicativos web em um ambiente gerenciado site do IIS, e nenhum trabalho de administração de infra-estrutura é necessária. Ele fornece uma baixa custo, inicialmente escalável e plataforma de grande utilidade. Cloud Services ou Plataforma como Serviço (PaaS): Segue-se a mesma idéia dos sites, mas com uma muito plataforma mais escalável e flexível adequado para altas exigências de qualidade de serviço e maior controle. Ele também lida com a maior parte do trabalho necessário para a confiabilidade e administração como PaaS. Windows Azure Serviços Móveis: Ele fornece um back-end nuvem escalável, acrescentando armazenamento estruturado, o usuário autenticação, notificações push, e back-end empregos e serviços para o seu Windows Store, o Windows Phone, Apple iOS, Android e HTML / JavaScript aplicações.

Dados

Gestão

Negócio

Analítica

Networking

Mensagens

Caching

Identidade

HPC

Mídia

As fontes de dados na nuvem e ferramentas SQL Azure para o uso do banco de dados rico e relacional e uma alta paridade com o SQL Server on- instalações, tornando mais fácil para mover bases de dados em instalações do SQL Server para a nuvem ou para sincronizar o diferentes ambientes. Sua maior vantagem é a alta disponibilidade de caixa e grande simplificação do manutenção / administração, uma vez que é delegado à infra-estrutura do Windows Azure. SQL Server no Windows Azure Virtual Machines é um cenário específico dentro da infraestrutura do Windows Azure Serviços. Para aplicações que precisam de funcionalidade completa do SQL Server, Virtual Machines é uma solução ideal. Windows Azure tabelas com base em dados não estruturados simples, com uma abordagem NoSQL, adequados para muito altamente requisitos de fonte de dados escaláveis. Windows Azure Blobs, projetado para armazenar dados binários não estruturados, como vídeo, arquivos ou dados de backup ou outros Os informações dados e relatórios binárias. Big SQL Reporting para funções semelhantes às do SQL Reporting Services quando você precisa de uma plataforma para criar relatórios. Hadoop no Windows Azure, que permite Big Data para ser hospedado como PaaS dentro do Windows Azure. Hybrid-nuvem e redes características Windows Azure Virtual Network para se conectar a sua própria rede local no local para um conjunto definido do Windows Azure VMs-uma abordagem semelhante para VPNs, mas orientada para os servidores e sub-redes. Se o seu aplicativo do Windows Azure é executado em vários datacenters, você pode usar Windows Azure Tráfego Gerente para inteligentemente encaminhar pedidos de usuários através de múltiplas instâncias do aplicativo. O Windows Azure Connect permite configurar conexões protegidas por IPsec (1:1 relações) entre certos computadores ou máquinas virtuais em rede e as funções em execução no Windows Azure da sua organização.

Mensagens e comunicação assíncrona Filas, adequado para a comunicação assíncrona entre diferentes aplicativos ou processos, o acesso à mesmas filas persistentes. Service Bus suporta mensagens persistente demais, mas é adequado para cenários mais avançados, como evento- aplicações e integrações acionados, publicar / padrões de subscrição, e para aceder facilmente no local datacenters da nuvem através da característica-relé em Service Bus (que também é útil para peer-to-peer aplicações com firewalls no meio). Paridade no local está disponível no Windows Server Service Bus.

Aplicação interna cache de dados e Internet cache HTTP Windows Azure Cache é um cache de memória distribuída. Ele pode ser usado como um serviço externo ou uma partilha implantação entre suas próprias máquinas virtuais. Windows Azure CDN é um "cache Internet" capaz de dados acessados-HTTP caching, como vídeo, arquivos, etc

Serviços de gestão de identidade Windows Azure Active Directory (AD) integra seus serviços de gerenciamento de identidade no local para uma única sign-on através de seus aplicativos na nuvem. É um serviço baseado em REST moderno que oferece gerenciamento de identidade e capacidades de controle de acesso para seus aplicativos na nuvem. Agora você tem um serviço de identidade através de Windows Azure, Microsoft Office 365, Dynamics CRM Online, o Windows Intune, e outros de terceiros nuvem serviços. Windows Azure Serviço de Controle de Acesso AD fornece uma maneira fácil para autenticar os usuários que precisam acessar suas aplicações web e serviços sem ter de levar lógica de autenticação em seu código complexo. Ele suporta o Windows Identity Foundation (WIF); provedores de identidade web (IPs), incluindo o Windows Live ID, Google, Yahoo e Facebook; Active Directory Services Federation (AD FS) 2.0, e protocolo de dados aberto (OData). Serviços de Federação do Active Directory (AD FS) (Windows Server) simplifica o acesso a no local datacenters, sistemas e aplicações que utilizam um acesso baseado em declarações (CBA) mecanismo de autorização para manter a aplicação segurança. AD FS suporta web (SSO) tecnologias que ajudam a tecnologia da informação (TI) single-sign-on organizações colaborar através das fronteiras organizacionais. AD FS no local podem ser integrados / estendida através do Windows Azure AD e ACS.

Computação de Alto Desempenho (HPC) Ele permite que você execute várias máquinas virtuais simultaneamente, todos trabalhando em paralelo em determinadas tarefas. Windows Azure fornece a HPC Scheduler, a fim de distribuir o trabalho em todos estes casos. Este componente pode trabalhar com aplicações de HPC criados para usar o padrão da indústria Message Passing Interface (MPI). O objectivo é torná-lo mais fácil de construir aplicativos HPC em execução na nuvem. Windows Azure Media Services Ele fornece um conjunto de componentes de nuvem para ingerir mídia, codificação, proteção de conteúdo, inserção de anúncios, streaming, etc, que simplificar muito o processo de criação e execução de aplicações utilizando vídeo e outras mídias.

Tabela 4-5

Referências

Criando aplicativos híbridos na nuvem no Windows Azure (Microsoft Patterns & Practices guia)

Aplicações que se deslocam para a nuvem (Microsoft Patterns & Practices guia)

Identidade e controle de acesso baseado em declarações (Microsoft Patterns & Practices guia)

Desenvolvendo aplicativos multi-tenant para a Nuvem, 3rd Edition (Microsoft Patterns & Practices guia)

Movendo seus aplicativos para o Windows Azure (Microsoft Patterns & Practices guia)

Enterprise Library 5.0 Integration Pack para o Windows Azure (Microsoft Patterns & Practices guia)

Windows Azure nuvem

http://msdn.microsoft.com/en-us/library/hh871440.aspx

http://msdn.microsoft.com/en-us/library/ff728592.aspx

http://msdn.microsoft.com/en-us/library/ff423674.aspx

http://msdn.microsoft.com/en-us/library/ff966499.aspx

http://msdn.microsoft.com/en-us/magazine/jj991979.aspx

http://msdn.microsoft.com/en-us/library/hh680918.aspx

http://www.windowsazure.com/

End-to-end cenários nos padrões de aplicações emergentes

Cenário: Conectado nativo do Windows loja de aplicativos

Utilizando o mapa de tecnologias introduzidas na Seção 3, "Visão geral" Figura 4-11 mostra um cenário típico e sua tecnologia

padrão de conexão para um aplicativo nativo moderno do Windows (incluindo tablet e telefone celular fatores de forma).

Cenário: Conectado Native Windows Store Apps

Figura 4-11

Este cenário seria semelhante se o nosso aplicativo cliente UI é um aplicativo nativo do Windows Store (por exemplo, um Tablet Windows) ou um

Aplicativos nativo Windows Phone. Dependendo de suas habilidades de desenvolvimento e requisitos de aplicação e prioridades, poderíamos escolher entre

NET / XAML, HTML5/WinJS, ou C + +, embora apenas. NET e C + + cobrir tanto o Windows Store e Windows Phone aplicativo nativo

desenvolvimento.

Para o desenvolvimento de serviços personalizados situado no back-end de aplicações modernas, a tecnologia recomendada para este cenário é

API Web ASP.NET. Isso proporciona um alto grau de flexibilidade, tendo uma luz e realizando estrutura para serviços de Internet,

geralmente indo abordagens como REST e OData ou JSON.

Em seguida, os serviços da API Web ASP.NET envolveria lógica de camada intermediária na forma de bibliotecas de classe. Costume NET e modelos de entidade (Usando o Entity Framework se acessar bancos de dados relacionais, ou qualquer outro API se acessar fontes de dados NoSQL).

Finalmente, poderíamos implantar nossos serviços e componentes do servidor em qualquer ambiente de desenvolvimento, embora na aplicação

padrões, emergente que normalmente seria implantá-lo em uma nuvem pública, como o Windows

Azure. Como dito anteriormente, uma característica típica de aplicações modernas é de cerca de com diferentes aplicativos para diferentes

contextuais / cenários pessoais (Como mostrado na Figura 4-12). Na maioria dos casos, esses cenários terão diferentes prioridades e

requisitos, que irão conduzir a sua decisão tecnologias. Por exemplo, no desenvolvimento de um aplicativo do Windows Store, para um concreto

cenário bastante próximo ao alimentações Internet e redes sociais APIs ou mesmo quando você quiser reutilizar habilidades e código JavaScript,

HTML5/WinJS desenvolvimento seria a melhor escolha. Em outros casos, se você quiser reutilizar os seus C # ou XAML habilidades ao ter

bom desempenho, você pode usar a abordagem NET / XAML. E, por vezes, ter o melhor desempenho possível de gráficos é um

prioridade, caso em que C + + seria a escolha certa.

Desenvolvendo para Windows Phone leva recomendações semelhantes em conta, se você escolher. NET ou C + +.

Outro ponto importante é que os serviços de back-end pode ser o mesmo para e voltar a ser utilizado por todos os clientes, diferentes cenários / você

escolher. No mínimo, você deve compartilhar as mesmas tecnologias de camada e servidor. Em outros casos, você pode ter dados diferentes

modelos, serviços e subsistemas otimizados para cada aplicação do cliente.

Vários aplicativos nativos para Diferentes Contextos

Figura 4-12

Cenário: Modern aplicações web para qualquer dispositivo móvel (comprimidos e telefone)

Figura 4-13 mostra um cenário de aplicação web moderna típica e seu padrão de conexão tecnologia ao direcionamento qualquer forma

fator e qualquer plataforma de cliente (Windows ou não-Microsoft OS).

Para o desenvolvimento de aplicações web moderna suporte a dispositivos móveis, as tecnologias recomendadas são ASP.NET MVC com

Suporte HTML5 para flexível e desenvolvimento web de controle total e Cliente HTML5 para LightSwitch projetos ao lidar com

cenários mais simples baseadas em dados.

Cenário: Modern aplicações web para qualquer dispositivo móvel

Figura 4-13

Arquitetura de exemplo simplificado para aplicações web modernas visam qualquer navegador e sistema operacional plataforma

Dependendo das necessidades e prioridades da web

aplicativo, você usaria diferentes abordagens. Por altamente dados

Aplicativos controlados, utilizando LightSwitch é recomendado, enquanto

complexo mais chamada cenários devem utilizar as tecnologias mais fina de

como grãos ASP.NET MVC e HTML5/JS simples.

Abordagem tecnologia mista para Web Apps modernos

Você pode ter vários módulos com diferentes prioridades e

características (-driven dados vs teias de interface do usuário mais

complexos) a mesma aplicação. dentro Nesses casos, você provavelmente vai adotar um

abordagem mista, conforme ilustrado na Figura 4-14.

Para este cenário, porque você está usando web padrão

tecnologias, pode ser alvo de qualquer dispositivo e em qualquer

sistema operacional, e não apenas um subconjunto de dispositivos móveis. Se o aplicativo tem como alvo diferentes-fatores de forma (telefone

e tablet), você deve considerar se cada fator de forma seria

beneficiar de um layout ou visão diferente.

Figura 4-14

Na Figura 4-15, o servidor de prestação de serviços (se são ASP.NET MVC ou LightSwitch) é capaz de renderizar código HTML

para apoiar alternativas multi-dispositivo. HTML pode ser processado para cada navegador baseado no agente de usuário web. No caso do ASP.NET

MVC, diferentes arquivos devem ser criados para cada agente de usuário, porque é de baixo nível crafting. Com LightSwitch, as diferentes

são representações gerados automaticamente, o que simplifica o desenvolvimento de aplicações multi-canal.

Rendering HTML Adaptação ao Formulário Fator

Figura 4-15

5. Padrões de aplicativos estabelecidos

Construir aplicações empresariais modernas não é apenas sobre a criação de novas aplicações móveis. As novas experiências exigidas pela

os usuários têm que ser muito bem integrados com os processos de negócios, de modo que essas experiências podem desbloquear o valor já

fornecido pelos principais aplicativos de qualquer empresa.

Esta secção vai cobrir as tecnologias comumente utilizados para esses padrões estabelecidos, bem como as formas recomendadas

para estender esses aplicativos para abraçar os conceitos de aplicativos de negócios modernos. Como descrito a seguir, esta seção é

estruturada principalmente pelas duas principais categorias de aplicações encontradas em qualquer empresa: aplicações de pequeno e médio porte, e

, grandes aplicações de missão crítica.

As aplicações de negócios de segmentação, as prioridades

Nesta seção, os padrões de aplicação estabelecidas são organizadas por prioridades de aplicação. Por exemplo, não é uma pequena, departamental

aplicação ou você está trabalhando em um longo prazo, core-business, aplicação de missão crítica? Essas categorias têm muito diferente

prioridades.

A partir dessas prioridades de negócios mencionados, aplicações esta seção segmentos de negócios em duas categorias:

Aplicações de pequena / média

Grandes, aplicações de missão crítica

Como ilustrado na Figura 5-1, as prioridades de aplicação de negócios pode ser usado para determinar qual categoria sua aplicação cai.

A partir daqui, você pode refinar as suas necessidades ou venha a perceber que os subsistemas em sua aplicação cair em categorias

separadas. Referindo-se a aplicações de apenas pelo seu tamanho pode ser

complicado. Por exemplo, deve ser considerado um Twitter

grande aplicação com base em seu número de usuários e

arquitetura altamente escalável? Ou será que a escassez

de sua funcionalidade significa que é um pequeno?

Padrões de aplicativos estabelecidos Segmentação por Prioridades

Assim, ao "tamanho aplicação", estamos nos referindo à

volume de complexidade, se está relacionado com a

complexidade funcional (como uma empresa personalizado

Recurso Planejamentosolução) ou arquitetônico,

escalabilidade e qualidade de serviço (QoS) complexidade

(Como o Twitter). Se o aplicativo em questão tem

complexidade mínima nestas áreas, para os nossos propósitos

seria considerado uma aplicação pequena / média.

Figura 5-1

Mesmo quando pequenas aplicações / médias não são

de missão crítica para a empresa inteira, eles ainda são cruciais para uma determinada área da organização (por exemplo, um departamento). Caso

por contrário, que construir um tal pedido?

As prioridades de pequenas / médias aplicações (ou subsistemas não-críticas) são geralmente a produtividade de desenvolvimento, obtendo

começou com facilidade, e rápido desenvolvimento para agregar valor ao negócio rapidamente. Por outro lado, as grandes aplicações de missão crítica e core-business (ou mesmo apenas subsistemas em vez de um aplicativo inteiro)

ter considerações adicionais e metas de longo prazo. Ao evoluir suas aplicações core-domínio durante um longo período de tempo,

atritos com as novas tendências de tecnologia pode surgir. Neste caso, você quer criar um software que implementa o seu tradicional

diferenciais de negócios. Além disso, neste cenário, você pode ter mais usuários simultâneos, então você pode querer ter um alto

grau de qualidade de serviço (QoS). A produtividade de desenvolvimento de curto prazo pode não ser tão importante, mas a longo prazo ágil

manutenção é uma necessidade. Sustentabilidade a longo prazo e facilidade de manutenção são fundamentais para grande missão crítica e core-

aplicações business que são sistemas "crescentes".

Como mostrado na Figura 5-2, dependendo destas

prioridades, você deve considerar diferentes desenvolver-

mento e abordagens de arquitetura, bem como

as tecnologias que melhor se alinham com os

abordagens.

Agilidade Desenvolvimento (Adaptar-se rapidamente a

alterações) é crucial para ambas as áreas, mas a sua

abordagens de arquitetura e até mesmo o escolhido

tecnologias são usualmente diferentes para cada

categoria.

Na maioria das vezes, no entanto, nenhuma aplicação cai

100% em uma categoria ou outra.

Como tal, a segmentação por prioridades devem ser

feito não apenas sobre as aplicações como um todo,

mas também sobre os subsistemas. Muitos aplicativos podem

tem alguns subsistemas core-business, mas também outros

subsistemas de garantia, que podem ser muito mais simples, como

mostrado o aqui na Figura 5-3.

Cada tipo de subsistema deve ser tratada e

concebido de uma forma muito diferente.

Padrões de aplicativos Fundada Segmentação

Figura 5-2

Segmentando Applications ou subsistemas?

Asubsistema pode ser definido como uma área diferenciada

de sua aplicação delimitado por um certo limite

(Possuir código e seu próprio modelo / dados), tão diferente

subsistemas podem ser desenvolvidas autonomamente por

diferentes equipes de desenvolvimento, com pequeno atrito.

Limitada por fronteiras claras, baseadas na consistência

relações, estes tipos de subsistemas são muito semelhantes ao Delimitada ao contexto no conceito Domain-Driven Design (DDD) jargão.

Este conceito será abordado na seção "Grandes aplicações de missão crítica e core-business", mais adiante neste documento.

Figura 5-3

Portanto, sempre que este guia discute categorias de aplicativos, também se refere ao subsistema categorias. No seu caso, ele vai

depender de seu domínio concreto, o contexto, cenários e requisitos de negócios.

Aplicativos de negócios de pequenas e médias

As aplicações de negócios em geral, seguem uma abordagem estabelecida quando apoiar ambientes controlados, como os funcionários e

departamentos da empresa. Esta seção concentra-se em aplicações de negócios de pequeno e médio portes, com um período relativamente curto,

vida evoluindo útil. Esses aplicativos também apoiar principalmente cenários dados centrados ou baseados em dados, muitas vezes referida como cenários

e CRUD. aplicativos Pequeno de negócios de médio porte costumam ter as prioridades apresentadas na Figura 5-4.

Figura 5-4

O "Competir velocidade e tempo mais curto para o mercado" e uma evolução contínua, incremental de experiências é a nova norma

que as organizações de TI precisam adotar para tornar seus negócios relevante e competitivo.

"Produtividade e custos mais baixos" é fundamental para certas áreas do negócio quando as aplicações devem ser desenvolvidas e ser instalado e

rodando em curtos períodos de tempo (provavelmente numa questão de alguns meses). Assim, a abordagem mais valorizado utiliza um

plataforma desenvolvimento que torna fácil de começar e não necessita de uma curva de aprendizagem inicial de alto custo. Isso significa que você vai querer fazer

um número limitado de decisões em relação à tecnologia, arquitetura e framework.

Com relação às ferramentas de desenvolvimento, é benéfico ter uma ferramentas de desenvolvimento produtivo, simplificados e transparentes que

agilidade proporcionam ao criar alta o ambiente ALM produção (Application Lifecycle Management e repositório de código fonte). Para

exemplo, uma nuvem / on-line e infra-estrutura de fácil começar-ALM (como o Visual Studio Team Foundation Service) é um ajuste perfeito para

desenvolver estes tipos de aplicações.

Construção de aplicações que se integram com ou são incorporados dentro Microsoft SharePoint e Microsoft Dynamics também estão em alta

demanda. Estes cenários são ainda mais atraente quando a aplicação tem requisitos adicionais relacionados com a colaboração,

compartilhamento, tópicos de gestão de documentos, ou de negócios comum operações (CRM e ERP).

O benefícios da nuvem de agilidade e redução de custos se encaixam perfeitamente com aplicativos de negócios de médio onde as partes

exigem interessadas agilidade no negócio ao publicar o aplicativo para produção. Por exemplo, não faz sentido desenvolver uma aplicação em duas

meses e, depois, esperar mais um mês antes de o aplicativo está instalado e funcionando no ambiente de produção. É por isso que tantos

empresas estão ansiosos para mover as aplicações para ambientes de produção ágil, sejam eles de nuvem pública ou privada

ambientes. Figura 5-5 resume o contexto de aplicações de negócios de pequeno e médio porte.

Figura 5-5

Como afirmado, produtividade de desenvolvimento geralmente é a prioridade mais importante para as pequenas aplicações de negócios de médio /, e é das um áreas onde . NET e Visual Studio brilhar. O trecho de um relatório da Forrester na Figura 5-6 destaca este tópico.

Figura 5-6

Os pontos seguintes incidem sobre os cenários mostrados na Figura 5-7:

Figura 5-7

Aplicativos de negócios centrados em dados independentes de pequena / média

-Aplicações de negócio web dados-centric

HTML5 cliente para projetos LightSwitch

HTML5 + ASP.NET (WebForms, MVC, SPA)

-Aplicações de negócios dados desktop-centric

WPF

Windows Forms

Cliente LightSwitch Windows Desktop

Aplicativos de colaboração e produtividade de negócios

-Apps para o SharePoint

-Aplicativos do Office

Aplicações de negócio web dados-centric

A maioria das aplicações centradas em dados abrangem as operações CRUD, incluindo cenários de detalhes mestre. Esses aplicativos também

para precisam implementar a lógica de negócio, mas não extensivamente. Terefore, este tipo de aplicações web em geral, não são grandes aplicações com

domínios complexos e um grande volume de regras de negócio, em vez disso, eles geralmente são simples, e fortemente impulsionada dados. A

prioridades maioria importantes para estas aplicações são produtividade, custo e valor. Seu objetivo é conseguir a ciclos de desenvolvimento curtos em

com um custo relativamente baixo, proporcionando valor para o negócio de forma ágil.

HTML5 é a tecnologia de cliente preferencial para a web, web sobre plug-ins como o Silverlight eo Flash. HTML5 pode ser consumida a partir de

qualquer dispositivo (PC, tablet, smartphone, e muito mais) e fortemente usa JavaScript (e muitas bibliotecas JavaScript poderosos, como jQuery)

e CSS.

Figura 5-8

Tabela 5-1 recomenda quando usar cada tecnologia, dependendo do contexto de sua aplicação web e as suas prioridades.

Tecnologia de camada de Apresentação abordagens para aplicações web de negócio

Technologies

Cliente para HTML5 LightSwitch projetos

ASP.NET Web Forms com Suporte HTML5

ASP.NET Páginas da Web

ASP.NET MVC

com HTML5

apoio

Quando usar e por quê

Cliente web LightSwitch Use-o quando o seu aplicativo web / módulo é principalmente orientado (CRUD) baseado em dados. Esta é a maneira mais fácil de criar-centric de dados, cross-browser, clientes da web móvel que podem ser executados em qualquer dispositivo moderno, tirar proveito de renderização de HTML automático, e se adaptar a diferentes fatores de forma. Estender com JavaScript, bibliotecas OSS JavaScript como jQuery Mobile, temas e CSS3. ASP.NET Web Forms com suporte HTML5 Para os desenvolvedores que estão familiarizados com Web Forms, esta abordagem fornece uma maneira fácil de iniciar o desenvolvimento mantendo o controle total sobre o código. Use bibliotecas como Modernizr para detectar HTML5 possui suporte e soluções alternativas. Use CSS3 para menos script e código mais sustentável. Use JavaScript e jQuery para a programação do lado do cliente.

Páginas da Web ASP.NET Páginas da Web ASP.NET ea sintaxe Navalha fornecer uma maneira rápida, acessível, e leve para combinar código do servidor com HTML para criar conteúdo web dinâmico.

ASP.NET MVC com suporte HTML5 Esta é a opção mais flexível e poderoso, com controle processamento full-HTML, forte teste de unidade capacidade de suporte, e fingindo. Use bibliotecas como Modernizr para detectar HTML5 possui suporte e soluções alternativas. Use CSS3 para menos script e código mais sustentável. Use JavaScript e jQuery para a programação do lado do cliente. Indicado para projetos mais complexos do que os projetos direcionados por LightSwitch ou Web Forms.

Tabela 5-1

Referências

ASP.NET Web Forms

LightSwitch HTML

http://www.asp.net/web-forms

http://msdn.microsoft.com/en-us/vstudio/gg491708

Para aplicações de negócio da web que são, cenários baseados em dados simplificados, a principal prioridade é a produtividade de desenvolvimento. Microsoft recomenda o uso de LightSwitch com seu cliente HTML5 sempre que cobre as suas necessidades. Usando LightSwitch é muito

simples ao criar modelos de dados e telas para operações CRUD, incluindo cenários de detalhes mestre. Em muitos casos,

você não precisa mesmo de escrever o código, embora você pode querer personalizar estilos e estender as operações com código através da

muitos pontos de extensibilidade que Lightswitch ofertas (JavaScript e pontos de extensibilidade. net).

Entretanto, ao usar LightSwitch, a aplicação será totalmente acoplado ao runtime LightSwitch, que é composta por

um fim-de-final, o motor transparente construída sobre ASP.NET e Serviços OData no servidor, e em jQuery Mobile no cliente quando

usando o cliente HTML5. Ela torna automaticamente telas, com base nos controles de dados para ser mostrado. Se o aplicativo não é data-

impulsionado e tem uma interface mais complexa para a maioria da sua superfície, LightSwitch não é, provavelmente, o melhor ajuste.

A vantagem dessa abordagem é que você vai obter a produtividade de desenvolvimento sem precedentes, quando uma elevada percentagem de

recursos LightSwitch mapeados para os requisitos da aplicação.

Outra possibilidade para aplicações web simples centrados em dados com uma boa produtividade de desenvolvimento inicial é ASP.NET Web Forms.

Eles apoio visual drag-and-drop de controles web e tem controles de grade que são fáceis de usar. Web Forms também é útil quando

você tem de ligação que se encaixa bem em um formato tabular dados simples, e que pretende fornecer uma maneira simples para os usuários a

Além atualizar disso, os registros. o Web Forms é geralmente bastante fácil se o fundo do desenvolvedor é sobre aplicativos de desktop, como o desenvolvimento, utilizando WinForms ou WPF.

Para cenários mais avançados, onde você está olhando para a Web UI mais flexível e poderosa (mas não o caminho mais fácil aprendizagem),

recomendamos a utilização de ASP.NET MVC mais HTML5/JavaScript, ou mesmo considerando abordagens avançadas como ASP.NET SPA (Single

Aplicação de página) para aplicações fortemente de JavaScript-centric.

Aplicações End-to-End Small / Medium Business Web: Cenário

Figura 5-9 mostra um padrão típico de conexão tecnologia para aplicações de pequeno / médio baseados na web de negócios. Independente do

abordagem de tecnologia de tomar (como LightSwitch ou ASP.NET), HTML5/JavaScript é a tecnologia de cliente web que é sempre

apresentar em desenvolvimento web moderna.

Cenário: End-to-end Small / Medium Web Business Application

Figura 5-9

As tecnologias e os motivos pelos quais você deve escolher uma ou outra tecnologia para serviços de construção são bastante semelhantes ao que

foi descrito anteriormente. Para mais detalhes sobre as opções de tecnologia de desenvolvimento de serviços (como a API Web ASP.NET, WCF,

etc), e para evitar a redundância, por favor, consulte a seção "Serviços" na Secção 4, "emergentes padrões de aplicativos."

Abordagem mista para aplicações de pequenas / médias empresas da web

Dependendo das necessidades e prioridades do seu aplicativo web, algumas abordagens são claras, como o uso de LightSwitch para-driven dados

aplicativos, tecnologias mais fina de grãos, como ASP.NET MVC e HTML5/JS simples para aplicações mais complexas, ou ASP.NET Web Forms se ele atende sua experiência às e habilidades.

Mas, novamente, considere que você pode ter vários subsistemas dentro

a mesma aplicação. Nestes casos, você provavelmente vai usar um misto

abordagem dentro do mesmo aplicativo, como o mostrado na Figura

5-10. Este é um exemplo de uma aplicação com 40 por cento CRUD-

operações baseadas desenvolvido utilizando LightSwitch e 60 por cento

tecnologias de granulação mais fina (como ASP.NET MVC) e avançado

abordagens (como SPA). SPA permite que você aproveite HTML5,

Javascript, jQuery, JavaScript e outras bibliotecas para construir a mais

áreas críticas e dinâmicos da aplicação. Que 60 por cento poderia

também ser desenvolvidos usando ASP.NET MVC ou Web Forms, dependendo

em suas necessidades e os seus conhecimentos. Usando o LightSwitch

pontos de extensibilidade, você pode consumir serviços externos de

JavaScript (Tier cliente LightSwitch) ou de código de servidor NET.

(LightSwitch Camada Intermediária).

Technologies Mixed-Web Abordagem para Aplicações Web Negócios

Figura 5-10

Aplicações de negócios dados desktop-centric

Você pode preferir a construir aplicativos de desktop (veja a Figura 5-11) mais do que as aplicações web porque sua aplicação envolve

entrada de dados pesados, porque você tem cenários offline complexas que envolvem o armazenamento local, a interoperabilidade COM, e

automação, ou talvez porque os usuários finais preferem aplicações desktop com base em suas necessidades de trabalho e de habilidades.

Figura 5-11

Dependendo da arquitetura de sua aplicação desktop, você vai precisar de determinadas tecnologias. Historicamente, o mais comum

arquiteturas para aplicações desktop são os estilos arquitetônicos de 2 camadas e 3 camadas mostrados na Figura 5-12.

vs

Figura 5-12

As tecnologias destacados que podem ser usados no desenvolvimento da camada do cliente em aplicações desktop pequeno / médio são o

seguinte:

. NET WPF

. NET Windows Forms

LightSwitch para o desktop

Tabela 5-2 recomenda quando usar cada tecnologia, dependendo de suas prioridades de aplicação e determinado contexto.

Tecnologia de camada de apresentação se aproxima para as pequenas médias empresas

/

área de trabalho aplicações

Technologies

Quando usar e por quê

. NET WPF

. NET Windows Presentation Foundation Esta é a tecnologia preferida para aplicativos de desktop baseados no Windows que precisam complexidade UI, estilos cenários de personalização, e com muitos gráficos para o desktop. WPF também tira proveito de pontos de vista de XAML.

E desenvolvimento de competências WPF são semelhantes aos da Windows Store desenvolvimento de competências, de modo a migração do WPF para

O Windows loja de aplicativos é mais fácil do que a migração do Windows Forms.

Tire partido das novas capacidades assíncronas simplificados em. NET 4.5 (assíncrono / esperam). Aproveite SignalR. NET cliente para comunicação bidirecional entre o cliente eo servidor.

NET WinForms.

NET Windows Forms.

LightSwitch cliente de desktop

Esta foi a primeira tecnologia de interface do usuário disponível na NET Framework para a construção de aplicações desktop É ainda uma boa opção para muitas aplicações de desktop de negócios. Windows Forms é mais fácil de usar e mais leve que o WPF para cenários simples, onde você não precisa de estilos de interface do usuário personalização. Ele fornece recursos de interface do usuário mais simples do que WPF e não é baseado em XAML, limitando o seu caminho para a frente Windows Store Apps. Também pode tirar proveito dos mais recentes. Capacidades NET como programação assíncrona com Cliente async de / await. desktop LightSwitch (de navegador) Se você já adotaram o LightSwitch meio-tier e soluções HTML5, você pode usar a área de trabalho experiência que LightSwitch suporta fora da caixa.

Referências

Aplicações desktop WPF

Tabela 5-2

http://msdn.microsoft.com/en-us/library/aa970268.aspx

http://msdn.microsoft.com/en-us/library/ms754130.aspx

Windows Forms

LightSwitch

http://msdn.microsoft.com/en-us/library/dd30h2yb.aspx

http://msdn.microsoft.com/en-us/vstudio/ff796201

Cenário: Small / Medium 2-Tier Desktop Application

Figura 5-13 mostra as possibilidades típicas com o padrão de conexão de tecnologia para um empresa de pequeno porte / desktop médio

aplicação com uma abordagem de duas camadas, onde os WPF / WinForms e componentes personalizados e código de acesso a dados estaria funcionando dentro da mesma camada do cliente (desktop PC).

Cenário: Small / Medium 2-Tier Desktop Application

Figura 5-13

O 2-tier abordagem de arquitetura antiga (cliente / servidor tradicional) não é recomendado na maioria dos cenários, porque

de questões como a dependência direta em drivers de banco cliente no cliente de PC, problemas se houver um firewall entre o PC cliente

eo servidor de banco de dados e escalabilidade limitada pelo servidor de banco de dados. No entanto, incluímos este cenário, uma vez que ainda é muito abordagem comum em aplicações estabelecidas. Neste cenário, você poderia usar o WPF como um cliente de desktop e acessar diretamente os dados

fonte (geralmente um banco de dados como SQL Server), utilizando tecnologias de acesso a dados, como o Entity Framework ou ADO.NET. Ao aplicar esta abordagem 2-tier, no mínimo, recomenda-se a ter separação de interesses dentro do seu. NET WPF

código, como separar a aplicação eo código de regras de negócios a partir do código de acesso a dados em diferentes camadas internas. Se você não fizer isso, seu aplicativo de desktop irá crescer monoliticamente e ser muito difícil de manter.

Cenário: Small / Medium 3-Tier Aplicativos Desktop

Figura 5-14 abaixo mostra um exemplo usando um padrão de conexão de tecnologia para uma pequena aplicação de negócio / área de trabalho médio com uma abordagem de três camadas.

Cenário: Small / Medium 3-Tier Aplicativos Desktop

Figura 5-14

Dependendo das necessidades e prioridades da aplicação desktop desejado, você usaria WPF como cliente de desktop e OData

Serviços ou LightSwitch OData serviços para aplicações orientadas a dados próprios (cenários CRUD). Alternativamente, você pode usar o WCF se o seu serviços são RPC / orientada para o comando.

As razões pelas quais você deve escolher uma ou outra tecnologia para os serviços são bastante semelhantes. Para mais detalhes sobre o

escolhas tecnológicas serviços de desenvolvimento (como ASP.NET Web API, WCF, etc), por favor consulte a seção "Serviços" da secção

4, "emergentes padrões de aplicativos."

Especialmente quando seus serviços não são apenas sobre acesso a dados (CRUD), mas também têm regras de negócios embutidas dentro dos

recomendado serviços, é para separar o código de regras de negócios a partir do código de acesso a dados e posicionar cada tipo de código em diferentes interno camadas (a seguir a separação das preocupações princípio), tendo as camadas dentro da camada de serviços.

Ao acessar a camada de dados, a tecnologia recomendada, por padrão, é Entity Framework. Neste simples e orientado dados

cenário, o uso mais comum de Entity Framework é através de seus designers visuais e modelo de primeira ou banco de dados de primeira

abordagens. Mas você também pode usar simples "classes de entidade Code First poco" se você precisar de controle total das classes de entidade.

Modernizar a aplicativos de negócios de desktop

Experiências em execução no ambiente de trabalho também deve ser construído considerando as expectativas do novo

NET oferece múltiplas

inovações para aplicações desktop para melhor atender a essas expectativas, bem como recursos que permitem a sua aplicação ser

alargada a novas plataformas sem mudanças na arquitetura e você ainda pode reutilizar o código. Construir seus aplicativos de desktop

com estas recomendações em mente irá estender sua expectativa de vida e torná-lo mais fácil para que você estenda a novos dispositivos, ou mesmo

migrar toda a aplicação no futuro.

Use o padrão de projeto Model-View-ViewModel (MVVM): Plataformas de cliente Microsoft (incluindo WPF) facilitam a

construir aplicações usando o padrão MVVM. Com este padrão você vai ter uma forte separação entre a exibição de estado e

comportamento, que irá ajudá-lo a criar um código limpo e de fácil manutenção que podem ser facilmente compartilhados entre vários

Utilize dispositivos. bibliotecas de classes portáteis para a lógica de cliente: NET. bibliotecas portáteis permitem binários para ser compartilhado entre vários plataformas, como o desktop, o Windows loja de aplicativos, aplicativos do Windows Phone, e outros. Implementar a lógica do cliente com

. Bibliotecas portáteis NET vai simplificar muito a criação de múltiplas experiências em várias plataformas.

Modernize a sua experiência de usuário: Conceitos que são exigidas pelos usuários finais de hoje pode ser implementado com a mais recente

inovações em. NET para o desktop. Princípios de design como "rápido e fluido", "autenticamente digital", e "fazer mais com

menos "pode ser aplicado para o seu aplicativo de desktop existente, empregando uma interface moderna para seu projeto XAML, cuidadosamente animações e de execução. usando programação assíncrona NET extensivamente.

Mova a lógica de negócio para o servidor: Aplicações de duas camadas (cliente / servidor) são significativamente mais difícil para estender a novos dispositivos. A abordagem recomendada é separar claramente a lógica de negócios em serviços que podem ser reutilizados mais tarde em outro dispositivos e fatores de forma.

Estender para a nuvem: Uma vez separadas a partir do cliente, o Windows Azure fornece várias soluções para mover o negócio

lógica para a nuvem. Transformar essa lógica em serviços de nuvem melhora a elasticidade e escalabilidade existente

soluções, tornando-os prontos para abraçar abordagens multi-dispositivo.

Parceiros do Visual Studio fornecem um conjunto de tecnologias que também irá ajudá-lo a modernizar seus aplicativos de rede;. Consulte a Tabela 5-3.

Parceiros do Visual Studio para modernização de aplicações NET.

Parceiros

Xamarin

ITR-Mobilidade iFactr

e Monocross

Mobilize.NET por Arte em Macio

Citrix

Quando usar e por quê

Xamarin fornece um meio de compartilhar o código C # a partir de suas aplicações dirigidas Windows ou Windows Phone com dispositivos iOS e Android. Ele fornece acesso à API subjacente para criar visualizações personalizadas, enquanto reutilizar o código da lógica de cliente entre dispositivos.

ITR-Mobilidade oferece uma solução para a construção de aplicações móveis corporativas em C # para entrega no grande plataformas móveis. Ele oferece serviços como Abstract UI e sincronização de dados da empresa para permitir de aplicações em uma variedade de dispositivos.

Mobilize.NET fornece soluções e serviços para a migração de aplicações legadas para plataformas modernas- incluindo a web, mobile, ea nuvem, transformando o código fonte existente em um novo código sem tempos de execução para a aplicação de saída.

Citrix Mobile SDK para aplicativos do Windows fornece um rico conjunto de ferramentas para desenvolvedores de mobilizar LOB Aplicativos do Windows ou escrever novas aplicações touch-friendly execução em servidores centrais (Citrix XenApp / XenDesktop) e acessados a partir de qualquer dispositivo móvel com o Citrix Receiver.

Tabela 5-3

Referências

Xamarin

ITR-Mobility iFactr e Monocross

Citrix

Mobile.NET

Diretório parceiro VSIP

http://xamarin.com/features

http://itr-mobility.com/products/ifactr

http://monocross.net/

http://www.citrix.com/mobilitysdk/

http://mobilize.net/

Visite o diretório parceiro VSIP para mais soluções fornecidas pela indústria Visual Studio Parceiros: https://vsipprogram.com/Directory

Modernizar aplicações baseadas em recipientes RIA

Alguns anos atrás, quando Rich Internet Application (RIA) recipientes e plug-ins eram populares, o contexto em que foi bastante diferente

a partir de hoje. Cinco anos atrás, RIA coberto a maioria das necessidades de implantação por apenas visando PCs baseados em Windows e

computadores a "revolução dispositivo" Macintosh. em Depois 2010, agora você tem diferentes dispositivos (tablets, smartphones e computadores) com operacional diferente

sistemas (incluindo o Windows 8, Windows Phone 8, iOS, Android e Chrome OS) e muitos deles não suportam RIA plug-ins.

Ao mesmo tempo, o HTML5 vem evoluindo para suportar cenários mais ricos que antes exigiam plug-ins. Atualmente, HTML5 é amplamente

suportado em todos os dispositivos e oferece uma alternativa melhor para o desenvolvimento multi-plataforma cliente de plug-ins tradicionais. As aplicações nativas também estão se tornando mais popular no mercado, uma vez que tirar o máximo proveito dos recursos específicos de cada

para dispositivo fornecer a experiência mais atraente para os clientes. Figura 5-15 ilustra estas tendências.

O que está mudando em UI Technologies?

Figura 5-15

A plataforma Microsoft oferece suporte a todas as três abordagens para interfaces de usuário (web, nativas, e RIA), mas também leva em conta que

experiências modernas através de dispositivos são desenvolvidos principalmente com tecnologias web e nativas. Decidir quando que fazer

transição dependerá em última análise as suas exigências e necessidades. A Microsoft está empenhada em apoiar a sua escolha e ajudando

ao longo do processo, como mostrado na Figura 5-16:

Se você está em transição para aplicações nativas, você pode aproveitar suas habilidades existentes e até mesmo código, visando XAML / .NET

nativamente em qualquer dispositivo Windows. Bibliotecas portáteis também vai permitir que você compartilhe seus binários entre diferentes

incluindo plataformas, Silverlight.

Para aplicativos HTML5 baseado em browser, Microsoft oferece ferramentas de liderança e estruturas para ajudá-lo a criar aplicações para

qualquer dispositivo com base nos mais recentes padrões. Interoperabilidade do Silverlight com HTML também permite uma transição gradual através

aplicações híbridas.

Se cenário alvo de sua aplicação ainda é suportado apenas pelo Silverlight (Por exemplo, proteção de conteúdo de vídeo) ou

padrões emergentes não são um requisito para as suas aplicações, no entanto, você pode continuar a usar o Silverlight. Silverlight é um maduro e tecnologia estável, e sua versão mais recente (Silverlight 5) foi lançado com suporte estendido para 10 anos para garantir que você

obter o máximo de investimentos existentes e permitem que você transição gradual para HTML5 ou soluções nativas.

O que está mudando em UI Technologies?

Figura 5-16

Apêndice A, "caminhos de migração do Silverlight", fornece informações e recomendações adicionais.

Modelo de aplicativo em nuvem para o Office e

SharePoint

Escritório 2013 introduziu o modelo de aplicativo em nuvem para estender Office e SharePoint através de aplicativos leves. Isto proporciona o valor

de suas aplicações de negócio através das aplicações de produtividade de escritório que seus clientes já usam. O modelo de aplicativo em nuvem é

construído sobre tecnologias web padrão como HTML, CSS, JavaScript, REST, OData, e OAuth no cliente, juntamente com qualquer servidor

tecnologia, incluindo o ASP.NET, no servidor. Se você é um desenvolvedor web, você pode usar suas habilidades existentes para criar aplicativos e tomar vantagem de ferramentas familiares, idiomas e serviços de hospedagem. Você pode implantar, atualizar e manter seus aplicativos mais rápido na

em nuvem, seguida, publicar e vender seus aplicativos na loja do Office, ou distribuir aplicativos de TI aprovados dentro de sua organização por meio de um interno App Catalog.

O modelo de aplicativo unificado vale para os seguintes tipos de aplicações:

Aplicativos do Office (Aplica-se para o Office 2013, o Office 365, o Project Professional 2013, Word 2013, Excel 2013, PowerPoint 2013,

Outlook 2013, o Outlook Web App, Excel Web App e Exchange Server 2013).

Apps para o SharePoint Servidor 2013 e SharePoint Online no Office 365.

Aplicativos do Office

Aplicativos do Office são baseados no modelo de aplicativo em nuvem para o Office e SharePoint, ver Figura 5-

17.

Figura 5-17

Um aplicativo para o Office é simplesmente uma página web HTML, mais um manifesto de aplicativo XML, como mostrado na Figura 5-18.

O que é um App para Office?

Figura 5-18

Conteúdo HTML usando padrões web podem ser expostos como Painéis de tarefas ou de conteúdo dentro de um documento do Office, e você pode

programaticamente acessar o conteúdo do Office a partir de JavaScript.

O manifesto do aplicativo é necessária a fim de publicar e ter seu aplicativo visível no Office Store público ou privado de qualquer

App Catalog.

Você pode criar os seguintes tipos de aplicativos para escritório:

Aplicativos painel de tarefas: Esses aplicativos aparecem no Painel de Tarefas de um

Aplicativos cliente Office. de conteúdo: Esses aplicativos aparecem dentro do conteúdo do documento do

Aplicativos Office. de correio para o Outlook 2013 e Outlook Web Access: Esses aplicativos aparecerá ao lado do item do Outlook que está aberta.

(Isso ser pode uma mensagem de email, solicitação de reunião, a resposta de reunião, cancelamento de reunião ou um compromisso.)

Figura 5-19 mostra alguns exemplos de aplicativos de conteúdo para o Office (em Excel, Outlook e Word). Todo o conteúdo especial mostrado na estes aplicativos são elementos criados usando páginas HTML embutido no cliente do Office, hospedando-lo dentro de um IFRAME e aceder ao Office

elementos do cliente a partir do código JavaScript.

Conteúdo App

Figura 5-19

Task Pane App

Correio App

As principais vantagens do modelo de novos-apps contra o VSTO legado (Visual Studio Tools for Office) modelo de aplicação (add-ins,

ou com base em documento) são:

Suporte Office Web Apps

Suporte para o Office RT

Mais fácil de migrar para futuras versões do Office

Além disso, com esta nova abordagem, os desenvolvedores web podem tirar proveito de suas habilidades para criar facilmente aplicativos para o Office.

Tabela 5-4 e Tabela 5-5 recomendar tecnologias relacionadas para o desenvolvimento de aplicações embarcadas em um cliente do Microsoft Office, em função das prioridades da aplicação e do contexto específico. Além das novas aplicações para o modo de Escritório, tecnologias legadas também estão incluídos.

Escolhas tecnológicas para o desenvolvimento do Office

Technologies

Aplicativos do Office modelo

- Office Developer

Ferramentas

- "Napa"

Quando usar e por quê

HTML5/JavaScript desenvolvimento cliente web embutido no Office É a tecnologia preferida para novas aplicações para o Office ea direção futura para extensibilidade Office.

Deve ser a escolha "por padrão" ao desenvolver para o Office 2013. Permite aceder aos documentos através da web ou do Office RT.

Mais adequado para execução de aplicativos on-line com acesso aos servidores que hospedam os aplicativos.

Office Add-ins

- Visual Studio

Ferramentas para o Office

(VSTO)

Office Add-ins e aplicativos baseados em documentos com VSTO (código. Conseguiu-NET no cliente)

Use-o se você precisa para criar aplicativos para escritório com versões mais antigas do que o Office 2013 ou cenários não abrangida pelos aplicativos para o modelo Office.

Ele é totalmente suportado. Mais adequado para execução de aplicativos off-line e cenários avançados.

Escritório VBA

Visual Basic for Applications (VBA) Use VBA para automação e soluções repetitivas ou prorrogações de interação do usuário. Suportado para automação de escritório e cenários de aplicação simples. Abordagem híbrida de aplicativos para o Office eo Office VBA. Quando o VBA é um modelo de documento e interage com um aplicativo para o Office através do conteúdo das partes XML documento / personalizados.

Tabela 5-4

Referências

Visão geral dos aplicativos do Office

VBA para desenvolvedores do Office

http://msdn.microsoft.com/library/office/apps/jj220082 (v = office.15)

http://msdn.microsoft.com/en-US/office/ff688774

Ferramentas e opções de tecnologia no desenvolvimento de aplicativos para o Office

Technologies

"Napa"

Escritório Ferramentas para Desenvolvedor para o Visual Studio

Quando usar e por quê

"Napa" (Lightweight IDE, codificação no navegador) É a maneira mais fácil de começar a desenvolver aplicativos para o Office e SharePoint. Ele não requer instalação do Visual Studio nas máquinas de desenvolvimento. Ele está disponível como um aplicativo gratuito para o desenvolvedor do Office 365 Site. Ferramentas Office Developer para Visual Studio (potência máxima) Use-o para o desenvolvimento profissional, quando você procura poder e flexibilidade. Ferramentas Office Developer para Visual Studio é gratuito, mas requer o Visual Studio Professional, Premium ou Ultimate.

Tabela 5-5

Em muitos cenários, aplicativos de negócios para o Office fornecer visualizações ou uma análise de dados de negócios. Um padrão típico para acessar

dados é através de serviços. Porque o consumo desses serviços será de JavaScript, o melhor ajuste é ASP.NET Web API Serviços

(REST / JSON / OData, e assim por diante). Se os serviços são simples e orientada a dados, uma abordagem mais fácil é usar serviços LightSwitch

ou OData WCF Data Services. No entanto, os aplicativos do Office pode ter um back-end web, pelo que o JavaScript não é a única opção. Você também pode acessar dados de negócio do lado do servidor utilizando ASP.NET.

As razões pelas quais você deve escolher uma ou outra tecnologia para serviços de construção são bastante semelhantes aos anteriormente

mencionado. Ao desenvolver serviços personalizados para serem consumidos a partir de aplicativos do Office, utilizando tecnologias como ASP.NET Web WCF, API, etc, por favor, consulte a seção "Serviços" na Secção 4, "emergentes padrões de aplicativos."

Cenário: Conectado Apps para o Office

Figura 5-20 mostra as possibilidades recomendadas para um aplicativo ligado para o Office que está consumindo serviços remotos e acessar

uma fonte de dados.

Usando os serviços do SharePoint é opcional. Um aplicativo para o Office pode ser isolado a partir do SharePoint, também.

Cenário: Conectado Apps para o Office

Figura 5-20

Apps para o SharePoint

Apps para o SharePoint são baseados no modelo de aplicativo em nuvem introduzido para o Office e SharePoint; veja a Figura 5-

21.

Apps para o SharePoint

Figura 5-21

Um aplicativo para o SharePoint é uma página HTML web ou uma aplicação web mais complexo (com base em qualquer motor de servidor, como o

Mesmo ASP.NET as MVC, tecnologias ou não-Microsoft, como o PHP, NodeJS, e assim por diante) que fornece páginas HTML. Por se tratar de uma aplicação web

Página regular, HTML o pode usar qualquer padrão web e tecnologia de biblioteca (HTML5/JS), como jQuery ou modernas abordagens SPA.

Ele também pode acessar e expor recursos do SharePoint como um

List, Serviços SharePoint Corporativos de Conectividade (BCS)

modelos, e implementar um fluxo de trabalho do SharePoint.

O que é um aplicativo para o SharePoint?

Como mostrado na Figura 5-22, a aplicação terá então que

ser registrado em SharePoint usando um manifesto do aplicativo. Uma

manifesto aplicativo é um arquivo XML que declara as propriedades básicas

do app juntamente com o local onde o aplicativo será executado eo que

fazer quando o aplicativo é iniciado. O modelo é realmente o mesmo que

o utilizado para aplicativos do Office.

Apps para o SharePoint pode ser mostrado no navegador da web como

webpages completos imersivos, como app-partes (com base em IFrames

dentro de páginas do SharePoint), e estendendo UI SharePoint

ações personalizadas.

Figura 5-22

Figura 5-23 mostra as diferentes opções de implementação de aplicativos para

SharePoint. Embora o uso da abordagem webpage completo pode parecer

muito isolado do SharePoint, não é, porque aplicativos para SharePoint

pode usar a mesma aparência de Controle usando o Chrome. Através

OAuth, o contexto de segurança do usuário também pode ser share entre

SharePoint e seu aplicativo personalizado. Dentro de apps, o SharePoint 2013

separa o código do lado do servidor a partir do servidor SharePoint, permitindo que você execute o seu código do lado do servidor em seu próprio

se servidor é no local web, ou na nuvem. Ao implantar um aplicativo no servidor SharePoint, esse app pode ter apenas do lado do cliente

código (HTML e JavaScript) ao invés de código do lado do servidor. Mas, como mostrado na Figura 5-24, autohosted e modelos hospedado pelo

permitir provedor que o código do lado do servidor em seu próprio servidor / serviços, dissociado dos servidores do SharePoint.

Figura 5-23

Opções para hospedagem Apps no SharePoint

Figura 5-24

O modelo autohosted é semelhante ao modelo hospedado pelo provedor, mas fornece um aprovisionamento transparente e automática e implantação de seu aplicativo de servidor no Windows Azure.

Tabela 5-6, Tabela 5-7 e Tabela 5-8 show e recomendar que a tecnologia a ser usada quando o desenvolvimento de aplicações relacionadas com a SharePoint, dependendo de suas prioridades de aplicação e contexto específico. Para este cenário, você também vai encontrar outras abordagens em Além das novas aplicações para o modelo do SharePoint.

Escolhas para o desenvolvimento do SharePoint

Technologies

Apps para o Modelo SharePoint

Os sites do SharePoint

Quando usar e por quê

Apps para o SharePoint (aplicativo de página inteira, peças de aplicativos e ações personalizadas UI) Abordagem padrão para aplicativos autônomos integrados com o SharePoint. Abordagem dissociado dos servidores do SharePoint.

Os sites do SharePoint personalização Use-o ao personalizar próprios sites do SharePoint. Modelos e páginas personalização por meio do recurso Gerente de Design e Visual Studio.

SharePoint full-

confiança fazenda

soluções

SharePoint fazenda no modo seguro soluções (Obsoleto)

Desenvolvimento-confiança total, extensões de administração, Web Parts tradicionais, etc Criar soluções de farm quando você não pode fazê-lo em um aplicativo para o SharePoint. Principalmente para personalizados extensões administrativas do SharePoint ou o desenvolvimento de ativos internos dentro SharePoint. Abordagem necessário para as versões do SharePoint com mais de SharePoint 2013.

Desenvolvimento Sandbox Esta abordagem tem sido substituído desde SharePoint 2013 (embora seja suportado no SharePoint 2013), portanto, é desaconselhável para construir novas soluções em área restrita. Use-o apenas em empreendimentos existentes para versões mais antigas do que o SharePoint 2013.

Tabela 5-6

Referências

SharePoint 2013: O que fazer? Fazenda Solução contra Sandbox vs App

Apps para visão geral do SharePoint

The New SharePoint

http://social.technet.microsoft.com/wiki/contents/articles/13373 sharepoint-2013-o-que- -a-fazenda-solução fazer-vs-sandbox-vs-app.aspx

http://msdn.microsoft.com/en-us/library/fp179930.aspx

http://sharepoint.microsoft.com/blog/Pages/BlogPost aspx? pid = 1012

Ferramentas e opções de tecnologia no desenvolvimento de aplicativos para SharePoint

Technologies

Quando usar e por quê

"Napa"

"Napa" (Lightweight IDE, codificação no navegador) É a maneira mais fácil de começar a desenvolver aplicativos para o Office e SharePoint. Ele não requer que você tenha o Visual Studio instalado nas máquinas de desenvolvimento.

Ferramentas Office Developer para o Visual Studio

Ferramentas Office Developer para Visual Studio (potência máxima) Use-o para o desenvolvimento profissional, quando você procura poder e flexibilidade. Ferramentas Office Developer para Visual Studio é livre com o Visual Studio Professional, Premium e Ultimate.

Office 365 Nuvem de Negócios Aplicações Visual Modelo de projeto Estúdio

Aplicações Office 365 Nuvem de negócios (Apps for SharePoint alimentado por LightSwitch) Use-o quando a criação de aplicativos baseados em dados (CRUD) ou consumindo recursos do SharePoint (listas e serviços) ou serviços não SharePoint e fontes de dados. A maneira mais fácil de criar formas flexíveis e aplicações orientadas a dados integrados ao Office 365 e SharePoint.

Tabela 5-7

Na maioria dos cenários, aplicativos de negócios para SharePoint requer acesso a algum tipo de dados, quer se trate de dados de negócios ou dados do Que SharePoint. o acesso de dados é fornecida através de serviços ou fontes de dados locais.

Tecnologias de serviços de back-end para aplicativos para SharePoint

Technologies

Cliente do SharePoint . NET Modelo ou REST / OData endpoints

SharePoint JavaScript cliente modelo de objeto

Personalizado

ASP.NET

API Web

LightSwitch

OData

Quando usar e por quê

Cliente SharePoint modelo. Objeto NET ou REST / OData endpoints Use-o quando se trabalha com listas do SharePoint, tipos de conteúdo, itens de lista, bibliotecas de documentos e qualquer tipo de operação relacionada aos recursos do SharePoint. Note-se que ao desenvolver aplicativos para SharePoint, não é possível usar o SharePoint gerido servidor Biblioteca de classes OM porque o aplicativo para o SharePoint é executado em um servidor remoto diferente. SharePoint REST / OData endpoints ou cliente. API gerenciada-NET Use-o ao consumir recursos do SharePoint diretamente do JavaScript em seu aplicativo.

Abordagem REST, orientado recurso Use-se os consumidores do serviço está prestes aplicativos nativos, clientes da web ou consumidores da Internet desconhecidas. É um abordagem flexível. API Web ASP.NET é uma estrutura que torna mais fácil para construir serviços HTTP que chegam a uma ampla gama de clientes, incluindo os navegadores e dispositivos móveis. Quadro leve, fácil de começar, e elevado grau de interoperabilidade com outras plataformas e formatos (JSON, OData, e assim por diante). Feito especialmente para os serviços REST. Abraça verbos HTTP como motoristas de aplicativos. Recursos orientada. Alta escalabilidade, graças à Internet (caches Akamai, o Windows Azure CDN, Level3, e assim por diante) com base em Verbos HTTP.

Abordagem REST, orientado recurso, maneira mais fácil de construir serviços

Serviços REST

Personalizado

Dados WCF

Serviços

Usá-lo na criação de serviços simples OData orientada a recursos. É a maneira mais fácil!

WCF Data Services Use-o quando seus serviços são dados / orientada a recursos e principalmente CRUD e data-driven. Suporta apenas OData. Simples de usar, mas oferece menos flexibilidade e controle do que o uso da Web ASP.NET API. Compartilha o mesmo bibliotecas centrais OData com API Web ASP.NET.

Tabela 5-8

Referências

Escolha a API direito previsto na SharePoint 2013

http://msdn.microsoft.com/en-us/library/jj164060 (v = office.15). aspx

Cenário: Conectado Apps para o SharePoint

Figura 5-25 mostra um padrão de conexão de tecnologia com as possibilidades típicas na criação de um aplicativo para o SharePoint.

Cenário: Conectado Apps para o SharePoint

Figura 5-25

Dentro deste cenário, a maioria das recomendações sobre tecnologias de desenvolvimento de aplicações web já descrito neste

documento são aplicadas de modo similar, mas vale a pena destacar em relação a tecnologias para a construção de serviços, o SharePoint está se

fortemente dirigindo para apoiar os serviços OData e aplicativos personalizados para o SharePoint também deve seguir esse caminho criação eo consumo de OData serviços (com base em qualquer tecnologia que suporta OData, como API Web ASP.NET, WCF Data Services e Serviços LightSwitch OData).

Grandes, aplicativos de negócios de missão crítica

A aplicação de negócio de missão crítica pode ser definida como qualquer aplicativo de negócios que é fundamental para o bom funcionamento dos

operações de negócios tradicionais. Se uma aplicação desta natureza falhar por qualquer período de tempo, você pode estar fora do negócio. Aplicações de missão crítica e core-business tem metas adicionais e prioridades específicas. A sustentabilidade a longo prazo e

manutenção são fundamentais para grandes e em constante evolução aplicações. Se você estiver trabalhando com grandes aplicações de missão crítica, você tem que lidar com duas preocupações principais:

Enfrentar a complexidade no domínio do núcleo da aplicação de negócio.

- Trata-se de perícia complexa de domínio e regras de negócio, e como efetivamente projetar estes no software.

- Essa preocupação deve conduzir arquitetura, design, e as decisões de implementação (como monolítico contra abordagens estruturadas / camadas) e as melhores práticas e padrões, dependendo do contexto (tais como Domain-Driven Projeto abordagens de arquitetura, arquiteturas de baixo acoplamento com base em técnicas de injeção de dependência e recipientes, e assim por diante). O design do aplicativo deve tomar a futura evolução e manutenção de uma aplicação em consideração.

Garantir QoS suficientes (qualidade de serviço) para aplicações grandes de missão crítica.

- Trata-se de disponibilidade, escalabilidade, segurança e assuntos semelhantes.

- Essa preocupação deve conduzir como medidas transversais (segurança, operações, instrumentação, e assim por diante) são projetados

e implementadas.

- Arquitetura de infra-estrutura também está intimamente ligada a QoS. Por exemplo, você deve considerar a arquitetura de infra-estrutura

no local ou na nuvem, dependendo escalabilidade necessárias e elasticidade, o tipo de usuários, e go-to-produção

agilidade necessita.

Figura 5-26 abaixo resume o que, quando e como lidar com esses tipos de aplicações.

Aplicações empresariais de missão crítica

Figura 5-26

. NET em aplicações de missão crítica de grandes e core-business

Ao longo dos anos,. NET evoluiu como um conjunto de estruturas de desenvolvimento de aplicativos, com foco na robustez, flexibilidade e

extensibilidade. A grande base de clientes da Microsoft expressou confiança em. NET para aplicações grandes de missão crítica, e

também tem reconhecimento de analistas, como mostrado no seguinte trecho de um relatório da Forrester recente (2012).

Líderes AD & D ver. NET como Java de igual para aplicações grandes e complexas. Windows Server, SLQ Server, ea NET Framework. eram um desafio à escala, mas não mais. Os líderes da empresa AD & D manifestou grande confiança na sua capacidade para apoiar as suas maiores aplicações no Windows / SQL Server / .NET. A barreira de desempenho e dimensionamento, segundo eles, é o código do aplicativo mal escrito, e não o próprio software de plataforma.

"escalas. NET também. Nós fizemos testes de carga com populações de usuários bastante significativos. A plataforma dá-nos uma boa opções de cache e gerenciamento de sessão, e nós gostamos do tratamento de exceções e acesso a dados também. Você tem algumas dessas coisas em Java Spring, mas em. NET são mais bem integrados. "(VP de aplicação desenvolvimento, a empresa de serviços financeiros)

Figura 5-27

Seleção de Tecnologia para grandes aplicações de missão crítica e core-business

Este guia não cobre de missão crítica do mercado de produtos próprios, tais como SAP, Dynamics ERP ou outros produtos específicos, que

incide apenas sobre o desenvolvimento personalizado.

Nota sobre tecnologias de desenvolvimento orientadas a dados Qualquer, a aplicação em grande missão crítica pode ter muitos subsistemas e

alguns deles poderiam ser garantia, non-core-business, e áreas de data-driven, mesmo simples. Por mais simples, subsistemas centradas em dados você pode usar as tecnologias baseadas em dados descritos nas "aplicações de negócio pequeno e médio porte", anteriormente. Este

seção não abrange as seguintes abordagens / tecnologias, em vez enfocando tecnologias para contextos limitados que

implementar o núcleo do domínio de seu sistema.

Qualquer, a aplicação em grande missão crítica pode usar uma ampla gama de tecnologias, a partir de diferentes tecnologias da camada de

para apresentação, implementações de modelo de domínio em última análise, com base em O / RMs, em muitos casos, o uso de cache, fluxo de trabalho, ônibus

diferentes serviço, filas tipos de mensagens, de fontes de dados (relacional vs NoSQL), etc Em suma, as escolhas tecnológicas dependerá dos cenários específicos e

prioridades que a aplicação possa ter.

Cenário: grandes, aplicações core-business

Cenário: grandes, aplicações core-business

(Muitos subsistemas)

Figura 5-28

Tabela 5-9 e Tabela 5-10 mostra e recomendar quando usar uma determinada tecnologia, dependendo da aplicação de missão crítica prioridades e contextos específicos.

Tecnologias de interface do usuário da Web para subsistemas core-business e de missão crítica

Technologies

ASP.NET MVC

com HTML5

apoio

ASP.NET

Página Única

Aplicação

(SPA)

Quando usar e por quê

ASP.NET MVC com suporte HTML5 Use-o se você quer a opção mais flexível e poderosa, com controle de renderização de HTML completo, melhor Unidade Prova apoio, e Fingindo capacidades. HTML5: Use as bibliotecas como Modernizr para a detecção de HTML5 possui suporte e soluções alternativas. Uso CSS3 por menos script e código mais sustentável. Uso JavaScript e jQuery para a programação do lado do cliente. Otimizações do Search Engine e URLs RESTFul são parte integrante da MVC.

Aplicação Página Única (SPA) baseado em ASP.NET MVC, HTLM5/JavaScript, Knockout, e Brisa SPA não é uma estrutura, mas um padrão de projeto que pode ser implementado utilizando ASP.NET MVC e pesado uso de bibliotecas JavaScript como Nocaute para suportar o padrão MVVM no JavaScript e como o Brisa JavaScript biblioteca para manipulação avançada de gerenciamento de dados. Use-o para aplicações web altamente interativas e atualizações de interface do usuário suaves (recarregar a página e servidor mínimo viagens visíveis redondas) e quando incluindo interações significativas do lado do cliente usando HTML5, CSS3, e JavaScript. Aproveite o código-fonte aberto SignalR JavaScript biblioteca cliente para comunicação bi-direcional entre o cliente eo servidor. Consumir serviços API Web ASP.NET a partir de JavaScript.

Tabela 5-9

O desenvolvimento web para aplicações de negócios de missão crítica deve oferecer-controle total e tecnologias refinadas, para que eles possam suporte de baixo acoplamento arquiteturas e criar o melhor UX web. Para o efeito, a Microsoft fornece ASP.NET MVC (controle total no servidor) e ASP.NET (SPA) Modelos de aplicativo Página Única, que fazem uso pesado de bibliotecas JavaScript como Knockout para suportar o padrão MVVM dentro de JavaScript. Há também a biblioteca Breeze para manipulação avançada de gerenciamento de dados. Tem outras estruturas úteis SPA JavaScript e bibliotecas, como Durandal e RequireJS.

Referências

Projeto de seda: Web do lado do cliente Desenvolvimento para navegadores modernos

ASP.NET MVC

ASP.NET SPA (Página Única Aplicação)

Modelo Breeze / Knockout

Quadro Durandal SPA

Biblioteca RequireJS

Modernizr: A detecção de recurso biblioteca para HTML5/CSS3

http://silk.codeplex.com/

http://msdn.microsoft.com/en-us/library/hh396380.aspx

http://www amazon.com/Project-Silk-Client-Side-Development- Microsoft/dp/1621140105 /

http://www asp.net / mvc /

http://www asp.net / páginas de aplicação única

http://www asp.net/single-page-application/overview/templates/breezeknockout- modelo

http://durandaljs.com/

http://requirejs.org/

http://www.modernizr.com

Tecnologias de interface do usuário de desktop para subsistemas core-business e de missão crítica

Technologies

. NET WPF

NET WinForms.

C + + (Win32 ou MFC)

Quando usar e por quê

. NET Windows Presentation Foundation Esta é a tecnologia preferida para aplicativos de desktop baseados no Windows que precisam complexidade UI, estilos cenários de personalização, e com muitos gráficos para o desktop. WPF também tira proveito de pontos de vista de XAML. Habilidades de desenvolvimento WPF são semelhantes aos da Windows Store desenvolvimento de competências, de modo a migração do WPF para O Windows loja de aplicativos é mais fácil do que a migração do Windows Forms. Tire partido das novas capacidades assíncronas simplificados em. NET 4.5 (assíncrono / esperam). Aproveite SignalR. NET cliente para comunicação bidirecional entre o cliente eo servidor.

NET Windows Forms. Esta foi a primeira tecnologia de interface do usuário disponível na NET Framework para a construção de aplicações desktop É um boa opção para muitas aplicações de desktop de negócios. Windows Forms é mais fácil de usar e mais leve que o WPF para cenários simples, onde você não precisa de estilos de interface do usuário personalização. Ele fornece recursos de interface do usuário mais simples do que WPF e não é baseado em XAML, limitando o seu caminho para a frente Windows Store Apps. Também pode tirar proveito dos mais recentes. Capacidades NET como programação assíncrona com C + async + (Win32 / await. ou MFC) Use-o para a construção de aplicações de alto desempenho da interface do usuário e os produtos muito grandes e complexas de longo prazo (tais como produtos comparáveis aos do Microsoft Office). Use-o para construir os melhores e mais desempenho cenários com muitos gráficos baseados no DirectX.

Tabela 5-10

Referências

Introdução ao WPF

Windows Presentation Foundation

Prism para WPF

Windows Forms

Aplicações C + + de desktop Win32

Aplicações C + + MFC de desktop

http://msdn.microsoft.com/en-us/library/aa970268.aspx

http://msdn.microsoft.com/en-us/library/ms754130.aspx

http://msdn.microsoft.com/en-us/library/gg406140.aspx

http://msdn.microsoft.com/en-us/library/dd30h2yb.aspx

http://msdn.microsoft.com/en-us/library/vstudio/hh875053 aspx

http://msdn.microsoft.com/en-us/library/vstudio/d06h2x6e.aspx

Os aplicativos de desktop são frequentemente utilizados em aplicações comerciais de grande porte, especialmente para sistemas de entrada de dados

As pesados tecnologias dentro preconizadas dos sistemas para existentes. essas aplicações são WPF (Windows Presentation Foundation), que fornece uma migração

caminho para da Windows Store aplicativos de negócios, e Windows Forms, que fornece uma solução mais fácil de usar e mais leve que o WPF

para cenários simples, onde você não precisa de estilos de interface do usuário personalização.

Tecnologias de desenvolvimento de UI modernos para aplicações nativas da Windows Store (Da Windows Store e Windows Phone apps / subsistemas)

As aplicações modernas orientada para o toque (da Windows Store aplicações para o Windows 8 ou Windows Phone) requerem inovador e

UX experiências convincentes, mas a empresa também exige que o apoio UX e alinhar com as preferências e habilidades de suas equipes.

A Microsoft oferece uma ampla gama de tecnologias e linguagens para criar aplicações nativas da Windows Store que apoiam a sua

habilidades da equipe de desenvolvimento, incluindo a NET / XAML, WinJS/HTML5, e C + + / XAML. Para reduzir a redundância de informações, as recomendações sobre a possibilidade de usar uma ou outra tecnologia são semelhantes ao

recomendações disponíveis na Seção 4, "padrões de aplicativos emergentes"; ver Tabela 5-11 e Tabela 5-12.

Tecnologias de camada intermediária para subsistemas core-business e de missão crítica

Technologies

Serviços

Quando usar e por quê

Orientação a Serviços Serviços contínuos são fundamentais para aplicações empresariais distribuídas. As prioridades são o desempenho

e apoio de serviços de luz HTTP inter-operável, padrões (REST, OData, SOAP, WS-*), e empresa

requisitos de serviço. A Microsoft fornece uma ampla gama de tecnologias baseadas em API Web ASP.NET, WCF,

e SignalR ASP.NET.

Modelo de Domínio

Modelos de domínio da entidade, agregados, domínio de lógica

O modelo de domínio é o núcleo da aplicação, onde as prioridades incluem complexidade combate em grande

domínios, criando o projeto certo para manutenção a longo prazo, e isolando o código de domínio (POCO entidades) de tecnologias de infra-estrutura. A Microsoft fornece maduros abordagens domain-modelo e fracamente tecnologias de acesso a dados acoplados, como Entity Framework, LINQ e ADO.NET, que podem ser utilizados quando

aplicando Domain-Driven-Design padrões.

Composição e

Vagamente Acoplado

Arquitetura

Arquitetura de baixo acoplamento, composição, integração, processos de negócios, fluxo de trabalho Cada aplicativo corporativo precisa de uma espinha dorsal que aborda cenários tipicamente encontrados nestes grande aplicações, como o projeto de arquitetura de baixo acoplamento com base na injeção de dependência e recipientes COI longa execução de processos e fluxos de trabalho, subsistemas de integração orientada a eventos, com base em alegação dissociado moderno implementação de segurança e transações. A Microsoft fornece tecnologias comprovadas que cobrem estas áreas, como inversão de controle (COI), contêineres (unidade e MEF), Windows Workflow Foundation (WF), Windows Identity Foundation (WIF), e. NET Framework Sistema.Transactions APIs, extensões reativas (Rx), etc

Tabela 5-11

Referências

API Web ASP.NET

WCF

Workflow Services

ASP.NET SignalR

Unidade

MEF

Sistema.Transactions

Extensões de Reativos (Rx)

http://www asp.net / web-api http://msdn.microsoft.com/en-us/library/hh833994 (v = vs.108). aspx

http://msdn.microsoft.com/en-us/library/ms731082.aspx

http://msdn.microsoft.com/en-us/library/dd456788.aspx

http://signalr.net/

http://unity.codeplex.com/

http://msdn.microsoft.com/en-us/library/dd460648.aspx

http://msdn.microsoft.com/en-us/library/system.transactions.aspx

http://msdn.microsoft.com/en-us/data/gg577609.aspx

Tecnologias de infra-estrutura para o core-business e de missão crítica subsistemas (CB)

Technologies

Mensagens

Segurança

Esconderijo

Fontes de Dados

Desenvolvimento

Infra-estrutura

Quando usar e por quê

Coordenação de mensagens assíncrono Composição, integração e abordagens orientadas a eventos usando APIs (como explicado acima no mid-tier tecnologias) precisa de uma infra-estrutura de base sólida a fim de escala. Os ativos necessários estão relacionados com infra-estrutura de mensagens assíncronas e enfileiramento de mensagens de infra-estrutura. A Microsoft fornece madura, sólida tecnologias de infra-estrutura, tais como Windows Azure Service Bus, Windows Server Service Bus, o Windows Azure Filas, o Message Queuing (MSMQ), e BizTalk Server / serviços.

Identidade, autenticação e autorização A Microsoft fornece tecnologias de infra-estrutura de segurança sólidas, como o Active Directory (AD), AD Federação Services (AD FS), o Windows Azure AD, etc A segurança recomendado desenvolvimento relacionados na moderna aplicações é baseado em "segurança baseada em declarações" e Windows Identity Foundation.

Aplicação interna cache de dados e Internet cache HTTP Windows Server AppFabric Cache e Windows Azure Cache é um cache de memória distribuída. Pode ser usado como um serviço de PaaS externa para suas máquinas virtuais / funções, ou a partilha de uma implementação de cache entre o seu próprio Windows Servers. Windows Azure CDN é um "cache Internet", capaz de armazenar em cache dados HTTP acessados, como vídeo, arquivos, etc Bancos de dados relacionais SQL, bancos de dados NoSQL não estruturados, e Big Data Quase qualquer tipo de aplicação de negócio precisa de fontes de dados em que a persistir dados de negócios. Dependendo contexto e as prioridades da aplicação, devem ser utilizados diferentes tipos de fonte de dados. As prioridades giram relacional em torno de riqueza de dados e capacidades transacionais, a disponibilidade de dados e escalabilidade, e maciça dados não estruturados aproxima. A Microsoft fornece tecnologias que cobrem estas prioridades, tais como SQL Server, SQL Azure, tabelas Windows Azure NoSQL e blobs, e HDInsight (Big Os dados, o Hadoop) no Windows Server ou o Windows Azure.

On-Premises, Nuvem, e híbrido-Cloud Todos os aplicativos corporativos precisam de uma infra-estrutura confiável que garante a disponibilidade do aplicativo, não importa quão o contexto muda no futuro. As prioridades incluem alternativas consistentes para no local ou em nuvem escolha, confiabilidade, desempenho, disponibilidade, escalabilidade, elasticidade, híbrido de TI, operações e monitoramento. Microsoft tem as soluções best-of-breed para estes requisitos com a infra-estrutura fornecida pela Windows Server, Windows Azure, e Microsoft System Center. Para mais informações sobre o Windows Azure e híbrido em nuvem, por favor consulte a Secção 4 ", a aplicação emergentes padrões ".

Tabela 5-12

Em, o desenvolvimento complexos e de grande aplicação de missão crítica, o posicionamento de uma lista de tecnologias não é suficiente.

Orientação abrangente sobre as abordagens de arquitetura e design é necessário para lidar com a complexidade envolvida com alvo específico

Domínio e qualidade do serviço. As seções a seguir neste guia introduzir várias abordagens importantes a ter

em conta em aplicações de core-business e de missão crítica, como Domain-Driven Design, CQRS, integrações event-driven,

modernizar aplicações core-business legados, e muito mais.

Abordagens e tendências para aplicações de core-comerciais de longo prazo

As seguintes abordagens, princípios e padrões são geralmente consideradas na construção de core-business e grandes, de missão crítica

aplicativos (e aplicações ainda menores, dependendo de suas prioridades):

Padrões de Arquitetura de Aplicações Corporativas (Tais como os de Martin Fowler)

Domain Driven Design (DDD) (Tais como o material fornecido por Eric Evans, Jimmy Nilsson, Vaughn Vernon, etc)

CQRS (Command & Consulta Responsabilidade Segregação) (Como "CQRS Journey" de padrões e práticas da Microsoft,

e outras fontes fornecidas por Greg Young, Udi Dahan, etc)

Origem de Evento (Tais como o material fornecido por Greg Young)

Arquiteturas dissociadas com base no princípio da dependência inversão

- Uso de injeção de dependência e inversão de controle (IoC) recipientes

Padrões e práticas da Microsoft; Unidade, Ninject, Castelo de Windsor, Spring.NET, e assim por diante

A orientação a serviços - Serviços REST, WS-*, Service Bus, serviços de nuvem elástica

S.O.L.I.D. princípios - Http://en.wikipedia.org/wiki/SOLID_ (object-oriented_design)

Projeto Behavior Driven (BDD) e TDD - (Isto é, Dan Norte, Chris Matts, etc)

Frameworks BDD: SpecFlow, NSpec, Cuke4Nuke, NBehave e MSpec, etc

Arquitetura de baixo acoplamento e do princípio da dependência inversão

Arquitetura de baixo acoplamento, juntamente com os princípios de dependência-inversão, técnicas e tecnologias, bem como SOLID

projeto orientado a objetos, aplicam-se vários cenários para aplicações core-business e de missão crítica. É interessante notar que, quando

em desenvolvimento aplicações de negócios pequenos / médios estas abordagens são também úteis, especialmente quando podem crescer as

de aplicações complexidade e de volume no futuro. Mas no desenvolvimento de grandes aplicações core-domínio, essas abordagens são

completamente fundamental.

Os componentes de um aplicativo deve ser colocado em camadas estruturadas distintas para que estejam em conformidade com os princípios como

"Separação de interesses" e obter benefícios como a manutenção mais eficiente. Também é importante dar uma atenção especial à forma como o

objetos interagem uns com os outros, ou seja, como eles são consumidos e, especialmente, como alguns objetos são instanciados a partir de outros. Principais técnicas dos objetos fracamente acoplados 'são baseadas no princípio da dependência-inversão (um dos princípios em SOLID:

http://en.wikipedia.org/wiki/SOLID (design orientado a objetos), em que a relação de dependência tradicional usado no objecto

orientação ("camadas de alto nível deve depender de camadas de baixo nível"), é invertida. Com esta abordagem, você alcança um objetivo

que importante, é ter de alto nível de objectos independente da execução de infra-estrutura, e, por conseguinte, independente do

tecnologias subjacentes.

Os principais estados de dependência inversão o seguinte:

Camadas de alto nível A. não deve depender de camadas de baixo nível. Ambas as camadas deve depender de abstrações (contratos / interfaces).

B. Abstrações não devem depender de detalhes. Os detalhes (implementação) deve depender de abstrações

(contratos / interfaces).

O objetivo deste princípio é dissociar os objetos de alto nível a partir dos objetos de baixo nível, de modo que é possível estender ou

alterar as ações finais coordenados por uma classe de alto nível por trocar a implementação das interfaces, onde você define o

dependências de alto nível de classe, mas, sem fazer qualquer alteração no código da classe de alto nível. Por exemplo, a possibilidade de executar

o mesmo código de um objeto de aplicação de alto nível (sem alterações de código) e consumir diferente subjacente

objetos de infra-estrutura / tecnologia que implementam as mesmas interfaces (abstrações) onde você basear suas dependências. Isto é

também relacionado com o princípio da substituição Liskov em SOLID (Http://en.wikipedia.org/wiki/Liskov_substitution_principle).

Os

contratos / interfaces definem o comportamento exigido dos componentes de baixo nível. Estas interfaces / contratos devem existir no

as

camadas mais altas (isto é, em DDD, que normalmente define a maioria das abstracções / interfaces dentro da camada de modelo de domínio, de

Modelo modo a de Domínio Camada detém os contratos que são as especificações exigidas para as camadas de infra-estrutura, a fim de trabalhar com

seu sistema). Essas camadas de infra-estrutura podem ser trocados no futuro seguindo o / Fechar princípio Open in SOLID

(Http://en.wikipedia.org/wiki/Open/closed_principle).

Quando os componentes de baixo nível implementar interfaces (que são colocados nas camadas de alto nível), isto significa que o baixo nível

componentes / camadas são as que dependem dos componentes de alto nível. Assim, a relação de dependência é tradicional

invertido (e esse é o porque é chamado o princípio de dependência-inversão).

Existem várias técnicas e padrões utilizados para esta finalidade:

Inversão de Controle (COI) recipientes

Dependency Injection (DI)

Inversão de Controle (COI) recipientes: Este delegados o dever de selecionar implementações concretas de nossas dependências de classes

a um componente ou fonte (qualquer recipiente concreto IoC de qualquer fornecedor) externo. Este padrão descreve técnicas para suportar um

"Plug-in" tipo de arquitetura, onde os objetos podem solicitar instâncias de outros objetos que eles necessitam e dos quais dependem.

Dependency Injection (DI) padrão: Este é realmente um caso especial de IoC. É um padrão onde são fornecidos objetos / dependências

para uma classe em vez da própria classe criando os objetos / dependências necessárias. A maneira mais comum de fazer isso é fornecer o

dependências através do construtor do objeto de alto nível.

Recipientes COI e injeção de dependência adicionar flexibilidade, compreensão e capacidade de manutenção para o projeto e irá resultar em

alterar o código real tão pouco quanto possível. Em vez disso, ele envolveu a tentar adicionar o código só na nova implementação / classes como o

projeto vai para a frente.

DI permite alterar o comportamento de uma classe sem alterar o código interno da classe apenas mudando as dependências

implementações. Isto está relacionado com o / fechar princípio, aberto em SOLID (Http://en.wikipedia.org/wiki/Open/closed_principle). O

técnicas de injeção instância do objeto são "injeção de interface," "injeção de construtor", "injeção de propriedade (setter)," e "injeção de

chamadas de método. "

Injeção de dependência como uma forma de qualidade arquitectónica

DI e IoC são utilizados para melhorar as qualidades arquitetônicas de um sistema orientado a objeto, tornando-o mais fácil de utilizar um bom design

técnicas. DI e IoC permitir o acoplamento fraco entre classes e suas dependências, para melhorar a testabilidade de uma classe, e

fornecer mecanismos de flexibilidade genéricos. Eles também podem aumentar consideravelmente as oportunidades para a reutilização de código, minimizando acoplamento direto entre classes e mecanismos de configuração.

O princípio da responsabilidade única em S.O.L.I.D. estados que cada objeto deve ter uma responsabilidade única (dê uma olhada

http://en.wikipedia.org/wiki/Single princípio responsabilidade). Estabelece que uma responsabilidade é uma das razões para alterar o código

(E alterações de código potencialmente introduzir bugs) e conclui dizendo que a classe deve ter um e apenas um motivo para

alterar. Este princípio é amplamente aceita pela indústria e favorece a concepção e desenvolvimento de pequenas turmas com apenas um

responsabilidade. Isso está diretamente ligado ao número de dependências, ou seja, objetos que cada classe depende. Se uma classe

tem uma responsabilidade, seus métodos normalmente tem poucas dependências com outros objetos em sua execução. Se há uma classe

com muitas dependências (por exemplo, 15 dependências), isso indica que é comumente conhecido como "mau cheiro" do código. Em

verdade, fazendo a injeção de dependência no construtor, você é obrigado a declarar todas as dependências objeto no construtor. Em

Neste exemplo, você poderia ver claramente que esta classe em particular, não parece seguir o princípio da responsabilidade individual, porque

é incomum para uma classe com uma única responsabilidade de declarar 15 dependências no construtor. Portanto, DI também serve como um

orientar para que possamos alcançar bons projetos e implementações, e oferece uma abordagem dissociação que você pode usar para injetar diferente implementações claramente.

Além disso, a injeção de dependência e inversão de recipientes de controle não se destinam a promover apenas o teste de unidade, ou

falsificações / simulações. Dizer que eles eram seria como dizer que o objetivo principal de interfaces é permitir testes. DI e IoC são cerca de

dissociação, mais flexibilidade, e ter um lugar central que permite manutenção de nossas aplicações. O teste é importante, mas

Não é a primeira razão ou a razão mais importante para usar o Dependency Injection e recipientes COI.

Recipientes DI / IOC

DI e IoC pode ser implementado com diferentes tecnologias e estruturas de diferentes fornecedores ou fontes. Tabela 5-13 lista um

alguns frameworks, mas você pode usar qualquer aplicação que você quer de uma maneira muito similar. O ponto importante aqui é entender

e aplicar os padrões e princípios de direito.

IoC (Inversão de Controle) containers-estruturas

Technologies

Microsoft Unity

Castelo de Projetos (Castelo de Windsor)

Microsoft

MEF

Ninject

Spring.NET

StructureMap

Autofac

Quando usar e por quê

Microsoft padrões e práticas Esta é atualmente a estrutura leve mais completa Microsoft para implementar IoC e DI. É um projeto de código aberto com Microsoft Public License (Ms-PL) de licenciamento.

Informações prolongado: http://msdn.com/unity ;http://unity.codeplex.com/

Castelo Stronghold Castelo é um projeto Open Source. É um dos quadros mais utilizados COI.

Informações prolongado: http://www.castleproject.org/

Gerenciado estrutura de extensibilidade MEF é uma parte do Microsoft. NET Framework. É um quadro de extensibilidade automático de ferramentas e aplicações, focando mais em extensibilidade UI e plug-ins. MEF não pode ser considerado como um recipiente tradicional COI, em vez disso, deve ser considerado como um quadro para a extensibilidade dinâmica e automática. Mas algumas de suas características se sobrepõem a um contêiner IoC típico. É um projeto de código aberto com Microsoft Public License (Ms-PL) de licenciamento. Informações prolongado: http://msdn.microsoft.com/en-us/library/dd460648 aspx ;http://mef.codeplex.com/

Por Nate Kohari Ninject é um injetor de dependência que torna o código mais fácil de entender, mais fácil de mudar, e menos erro de bruços. É um projeto de código aberto.

Informações prolongado: http://www.ninject.org/

SpringSource (uma divisão da VMware) Spring.NET é um framework para a construção de aplicações corporativas. Ele suporta as capacidades de IoC, mas também AOP (Programação Orientada a Aspectos) capacidades. É um projeto de código aberto. Informações prolongado: http://www.springframework.net/

Por vários desenvolvedores da comunidade NET OSS. StructureMap é o mais antigo instrumento de IoC / DI para. NET, disponível desde Junho de 2004. É um projeto de código aberto. Informações prolongado: http://structuremap sourceforge.net / default.htm

Por vários desenvolvedores da comunidade NET OSS. Autofac gerencia as dependências entre as classes para que as aplicações ficar fácil mudar à medida que crescem de tamanho e complexidade. É um projeto de código aberto.

Informações prolongado: http://code.google.com/p/autofac/

LinFu

Funq

Por Philip Laureano O quadro LinFu é um conjunto de bibliotecas que estendem a CLR, fornecendo IoC, AOP, a DBC e outros recursos. É um projeto de código aberto.

Informações prolongado: https://github.com/philiplaureano/LinFu

Por Daniel Cazzulino e outros desenvolvedores da comunidade NET OSS. Funq é um framework de DI de alta performance que elimina toda a reflexão em tempo de execução através do uso de lambdas e funções genéricas como fábricas É um projeto de código aberto. Informações prolongado: http://funq.codeplex.com/

Tabela 5-13

A maioria dos contêineres IoC / DI também suportam o padrão de Intercepção. Este padrão introduz outro nível de engano. Este

técnica coloca um objeto (um proxy) entre o cliente eo objeto real. O comportamento do cliente é o mesmo que se interagiram

diretamente com o objeto real, mas o proxy intercepta-lo e resolve a sua execução, colaborando com o objeto real e outro

objetos, conforme necessário. Intercepção podem ser utilizados como uma forma de implementar o AOP (Aspect Oriented Programming).

Injeção de dependência para qualquer estilo arquitetônico

Finalmente, é importante ressaltar que um projeto dissociado utilizando DI / IoC é também benéfico no desenvolvimento de aplicações de quase

qualquer tipo e de quase qualquer abordagem arquitetônica. Claro, ele se encaixa perfeitamente em arquiteturas que devem ser dissociados, pois

de seu design original, como Domain-Driven Design (DDD) e comando de consulta Segregação Responsável (CQRS). No entanto, ele

Também funciona muito bem em simples estilos arquitetônicos como 2 camadas e CRUD abordagens (por exemplo, usando uma abordagem mais

apenas simples em com ASP.NET base MVC e 2 camadas). Se você aplicar DI / IoC e os princípios relacionados nesses contextos mais simples, você também vai ficar

benefícios. semelhante Por outro lado, não há dúvida de que a maior e mais complexa uma aplicação pode ser, mais benefícios você terá

começa a partir de arquiteturas dissociados.

Estilos de arquitectura para aplicações de core-business

Existem muitos estilos arquitetônicos utilizados por arquitetos e desenvolvedores de software. A seguir estão algumas abordagens típicas que

pode ser implementado com . NET Framework:

Arquitectura tradicional Layered (Camadas de cima para baixo lógicas)

Projeto de arquitetura em camadas Domain-Driven (Camadas lógicas onde o coração é a camada de domínio)

CQRS abordagem arquitetônica (Camadas lógicas e níveis físicos)

Arquitetura 3-Tier (Camadas físicas)

Arquitetura N-Tier (Camadas físicas)

Arquitetura Orientada a Serviços (SOA) (Maior nível de orquestração)

Arquitetura orientada a eventos (EDA) (Maior nível de orquestração)

Muitos deles são complementares, porque você pode implantar uma arquitetura lógica em camadas, seguindo um físico N-Tier específico

arquitetura. Você também pode ter uma arquitetura orientada a serviços (SOA) ou Event Driven Architecture de alto nível (EDA) que orquestra

muitos serviços que são internamente concebido como uma arquitetura em camadas,

etc

O ponto importante é que nenhuma arquitetura particular, é ideal para todas as situações. Ainda mais, quando se trata de aplicações de grande porte,

você geralmente não deve aplicar uma única arquitetura abordagem de nível superior. Por outro lado, você deve projetar grande composite

aplicações compostas por vários subsistemas (ou contextos delimitadas no Domínio-Driven Projeto jargão), onde a abordagem certa vontade

ser para aplicar diferentes estilos de arquitetura com base na natureza e as prioridades dos subsistemas. Você pode até mesmo decidir que, para

subsistemas certos colaterais ou contextos delimitadas dentro da sua aplicação geral, a abordagem correta é um simples CRUD baseado em dados e

abordagem, e só para o seu core-domínio (core-business), pode ser necessário aplicar uma arquitetura mais avançada e dissociada

como abordagens e padrões de Domain-Driven, como ilustrado abaixo na Figura 5-29.

Subsistemas / Contextos delimitadas com diferentes arquiteturas

Figura 5-29

Acontexto limitado (BC) é mais preciso do que o termo subsistema (embora às vezes eles podem coincidir). O original

definição em Domain-Driven Design é, "A aplicabilidade delimitada de um determinado modelo. Limitada Contextos dá aos membros da equipe

uma compreensão clara e compartilhada do que tem que ser consistente e que pode desenvolver de forma independente " (Eric definição Evans), onde uma característica importante é que cada contexto limitada tem o seu próprio modelo de domínio e, em muitos casos, até mesmo o seu próprio banco esquema de e dados banco de dados.

Não há "bala de prata" ou uma arquitetura de direito exclusivo para um determinado caso. Você não pode ter "uma única arquitetura para governar toda aplicações a ou todos os subsistemas ou contextos delimitadas. ", dependendo das prioridades de cada subsistema (contexto delimitado), você

deve escolher uma abordagem diferente. Vai ser um desastre se você usar uma abordagem orientada a dados muito simples (CRUD e RAD) para uma

aplicativo que será evoluindo e crescendo a sua lógica de negócios por muitos anos, porque, eventualmente, a aplicação vai ficar

convertido em um "grande bola de lama", e que a aplicação será insustentável no longo prazo. Contudo, o oposto também é

verdade. Por exemplo, não faz sentido construir uma aplicação muito simples de manutenção baseado em dados da tabela a implementação de um muito avançada e "estado da arte" arquitetura, só porque você quer usar a mesma abordagem "padrão" para todos os seus

desenvolvimentos. Vai ser muito caro e comparável a "construção de uma bicicleta com peças de foguetes!" Por isso, a abordagem certa para

aplicativos de negócios grandes é "dividir e conquistar!"

Em resumo, abordagens e estilos arquitetônicos deve ser aplicada a determinadas áreas dentro de grandes aplicações, ao invés de

como de nível superior arquiteturas prescritivas.

Então, é claro, o foco agora se desloca para as seguintes perguntas: "Como faço para identificar os subsistemas ou contextos delimitadas?" E até mesmo ainda: "Como faço para integrar esses contextos limitados?" Abordamos muitas destas perguntas neste guia, mas para mais detalhado

informações sobre o conteúdo de design comum Domain-Driven e outras abordagens relacionadas, consulte as seguintes referências.

Referências

Domain-Driven Comunidade Projeto e Conteúdo

http://dddcommunity.org/uncategorized/bounded-context/

http://dddcommunity.org

http://dddcommunity.org/books/

http://www.agilification.com/file.axd?file=2010/8/CQRS+DDD+Notes+Greg+Y

oung.pdf

Boneco de Arquitetura: alinhados verticalmente Sinergicamente particionado (VASP)

Arquitetura (Conceito Comparável a Limitada-Contexto)

Por Roger Sessions

Comunicação entre Limitada Contextos (Microsoft padrões e práticas CQRS Journey)

Entity Framework domínio de Modelos em DDD Contextos delimitadas (Delimitada-Context-View em vez de pura dissociada DDD aC)

http://simplearchitectures.blogspot.com/2012/12/the-snowman-architecture-

part-three.html

http://msdn.microsoft.com/en-us/library/jj591572 aspx

http://msdn.microsoft.com/en-us/magazine/jj883952.aspx

Modernizar aplicações corporativas de missão crítica

Ao criar novos, grandes aplicações de missão crítica, as abordagens escaláveis e elásticos actuais devem ser aplicadas. No entanto, a maioria

aplicações corporativas existentes não foram construídos com motores assíncronos e abordagens orientadas a eventos, e eles não suportam

scale-out e arquiteturas elásticas. Em muitos casos, é preferível tratar essas aplicações como sistemas legados para ser integrado

atualizados fachadas (ou baseada em serviços baseados na web). Essa integração deve ser feita enquanto a construção de uma nova mensagem

sistema assíncrona- de integração orientada como um organizador de cross-channel. As mudanças e atualizações para os aplicativos criados devem se concentrar

em áreas relacionadas com a inovação (como em aplicações modernas) ou áreas relacionadas com a escalabilidade e desempenho. No entanto,

com quando sistemas se trata legados, a escalabilidade pode ser alcançado mais facilmente através da construção de serviços de front-end e caches na nuvem (as anteriormente mencionado fachadas) em vez de reconstruir toda a aplicação de missão crítica a partir do zero. Depois, em paralelo, você pode re-arquiteto

os sistemas internos por trás das fachadas como orçamento e tempo permitir.

Esta modernização é precisamente um dos cenários deste guia se concentra nas próximas seções.

Cenários para aplicações personalizadas grandes de missão crítica

As seções seguintes abordam cenários típicos para o costume de grandes aplicações de missão crítica:

Cenário: Subsistema de Domain-Driven (Contexto Delimitada)

Cenário: CQRS Subsystem (Contexto Delimitada)

Cenário: Comunicação Diferentes Contextos Limitada

Cenário: Aplicações Modernização Legado de Missão Crítica empresa

Cenário: Subsistema de Domain-Driven (Contexto Delimitada)

Este cenário abrange complexos subsistemas core-business. Neste caso, a palavra "complexo", os sistemas que têm um volume alto

de constante mudança de domínio / lógica de negócios que vai estar evoluindo durante anos. Embora a sua camada de apresentação pode variar (web, desktop ou dispositivos móveis modernos), o maior volume de investimentos, design e

desenvolvimento é no lado do servidor / serviços onde a lógica de negócios / domínio é geralmente colocado.

Este tipo de aplicação (ou subsistema) é caracterizado por ter um tempo de vida relativamente longo e pode ser necessário para absorver uma considerável quantidade de mudanças evolutivas. Manutenção contínua crítica nestas aplicações, por isso uma das prioridades mais importantes é a

investir em princípios de arquitetura, design e desenvolvimento que irá facilitar a manutenção e as mudanças a longo prazo. Se o

aplicação cresce substancialmente, que pretende garantir o mínimo impacto possível para o código real. É por isso que monolítico

abordagens são o pior abordagem para estes tipos de aplicações.

Como mencionado anteriormente, em aplicações complexas, o comportamento das regras de negócio (lógica de domínio) é muitas vezes sujeitos a

capacidade alterações, de de modo modificar, a construir e realizar testes isolados (teste de unidade e de zombaria) em camadas de lógica de domínio de uma forma fácil e

forma independente é fundamental para uma manutenção sustentável. Alcançar este objetivo importante requer acoplamento mínimo entre o modelo de domínio

(Modelo de entidade, incluindo a lógica e as regras de negócio) eo restante das camadas do sistema (as camadas de apresentação, camadas de infra- estrutura, persistência, dados e assim por diante). Para o efeito, os modelos de persistência ignorantes e projetos dissociados com base em abstrações são

necessária normalmente neste contexto.

Além disso, porque estas aplicações a longo prazo normalmente terá uma vida muito longo (vários anos, pelo menos), eventualmente, o

tecnologias disponíveis irá evoluir ou ser substituído. Por conseguinte, um objectivo importante para os sistemas de longo prazo é capaz de se adaptar

infraestrutura às / mudanças tecnológicas com um impacto mínimo para o resto da aplicação (modelo de domínio, regras de domínio, os dados

estruturas comunicadas aos outros níveis [DTOs], etc) Mudanças na infra-estrutura tecnológica de uma aplicação (tecnologias para dados

acesso, barramento de serviço, segurança, operações, instrumentação, etc) deve ter um impacto mínimo sobre camadas de nível superior no

aplicação, principalmente na camada de modelo de domínio da aplicação.

As tendências em arquiteturas de aplicações de longo prazo são cada vez mais orientada para promover esta dissociação entre classes / objetos

e também entre áreas verticais (contextos delimitadas). Domain-Driven Design (DDD) é um excelente exemplo desta tendência como um

abordagem para o desenvolvimento de sistemas de software funcionais complexos.

A abordagem DDD utiliza um conjunto de técnicas para analisar o seu domínio e para a construção de um modelo conceitual que captura os

dessa resultados análise. Você pode então usar esse modelo como base para a sua solução. A análise e modelo na abordagem DDD são

especialmente bem adequado para a construção de soluções para domínios grandes e complexos. DDD também se estende a sua influência para

processo outros aspectos de desenvolvimento da de software para ajudar a gerenciar a complexidade. Os princípios fundamentais em Domain-Driven Design são:

Foco no domínio do núcleo

Colaboração direta entre "especialistas de domínio" e a equipe de desenvolvimento

Fale um linguagem ubíqua dentro de um contexto delimitado explícita (subsistema)

Aplicar certo DDD arquitetura e design comprovado padrões

Portanto, DDD é muito mais do que apenas uma proposta de arquitetura, é uma forma de gestão de projetos, trabalho em equipe para identificar um

"Linguagem ubíqua" baseado em "Conhecimento esmaga". Isto leva a interação contínua entre o desenvolvimento

equipe com especialistas de domínio para capturar as partes importantes do domínio do modelo, a busca permanente por melhores abstrações,

refactoring, e melhoria do modelo. Developers 'conhecimento do domínio cresce ao longo do tempo, junto com os especialistas do domínio'

capacidade de formalizar ou destilar seu conhecimento de domínio. Ao projetar DDD arquiteturas lógicas, um contexto delimitada complexo deve ser dividida em camadas. Este projeto deve ser

coesa, dentro de cada camada, mas é evidente que deve definir as diferentes camadas dentro do sistema. Dependências entre objetos deve

se basear em abstrações. Além delinear claramente e isolar a camada do modelo de domínio do resto das camadas,

como as camadas de infra-estrutura com base em tecnologias específicas (Como as tecnologias de acesso a dados). Tudo deve girar em torno de

o domínio, porque "Do camada de domínio é o coração do software " em aplicações de núcleo de domínio.

Por isso, dentro de um contexto concreto limitado, todo o código relacionado com o modelo de domínio (por exemplo, entidades de domínio e

deve serviços ser de colocado domínio) em uma única camada. O modelo de domínio não deve persistir / save em si, nem deve ter dependências diretos

tecnologias subjacentes. Deve concentrar-se exclusivamente em expressar o modelo de domínio (dados e lógica). O. NET Quadro e

Entity Framework aliviar significativamente esta implementação do modelo ao usar POCO Code-First entidades que são "persistente

ignorante ".

Esta camada é semelhante à Figura 5-30 (seguindo as tendências de estilos arquitetônicos DDD), onde você poderia ter limitado adicional

contextos com outras abordagens arquitetônicas diferentes:

Simplificado DDD Arquitetura em Camadas Dentro de um pedido Grande

Figura 5-30

Nesta figura, as setas representam as dependências entre os diferentes componentes e camadas. A principal diferença entre um

Abordagem DDD em camadas e uma abordagem em camadas de cima para baixo tradicional é que a camada de modelo de domínio não tem

dependência a outra camada. de qualquer Esta abordagem é baseada em abstrações (interfaces definidas dentro da camada de modelo de domínio e as respectivas

classes de implementação são colocados em outras camadas) e modelos de entidade POCO (como usar Microsoft Entity Framework Entidades POCO

e Code-First abordagem). É por isso que a camada de modelo de domínio está em conformidade com o persistência princípio ignorante em relação a

tecnologias dados de acesso que você pode usar.

Você deve aplicar abordagens avançadas (como DDD ou CQRS) apenas dentro dos contextos limitados que se concentram no núcleo do domínio de

da aplicação. Outras cauções e contextos limitados simples ou subsistemas pode ser implementado seguinte orientada a dados e

Abordagens CRUD, como mostrado na Figura 5-30.

A arquitetura lógica mostrada na Figura 5-30 é a abordagem de arquitetura interna. Você pode ter arquiteturas de nível superior

orquestrar diferentes serviços e outras arquiteturas físicas e de infra-estrutura específicos (tiers e serviços elásticas em privado ou

as nuvens públicas, e assim por diante), onde você implantar esses serviços, como mostrado na Figura 5-31 e na Figura

5-32.

Figura 5-31

Figura 5-32

Os serviços utilizados por uma aplicação em 3 camadas pode ser composto de uma série de contextos limitados. Cada contexto delimitada poderá ter

fonte um de dados única, ou poderiam compartilhar as mesmas fontes. É importante que cada contexto limitada tem a sua própria entidade de domínio

modelo, o que normalmente significa o seu próprio esquema de banco de dados. Em SOA, um serviço poderia corresponder a um contexto limitado, mas não é obrigatória. Um contexto delimitada também pode ser composta por várias serviços, ou vice-versa, um grande serviço pode ser constituído por vários contextos delimitadas.

Contextos delimitadas e modelos de domínio

Contextos delimitadas lidar com diferentes aspectos do domínio que representa um conceito singular no mundo real (domínio). Delimitada

contextos são componentes autônomos, com os seus próprios modelos de domínio e sua própria linguagem ubíqua (domínio concreto

termos). Eles não devem ter quaisquer dependências entre si em tempo de execução e deve ser capaz de funcionar de forma isolada.

Contextos delimitadas dar os membros da equipe uma compreensão clara e compartilhada do que tem que ser consistente e que pode desenvolver

independentemente. Portanto, para cada contexto de limitada, você precisa definir um limite em torno da aplicabilidade delimitada e

consistência de um modelo específico. Devido a isso, cada contexto delimitado geralmente tem a sua própria linguagem ubíqua que os impactos

o seu próprio modelo, então quando você está falando sobre conceitos semelhantes e entidades em diversos contextos delimitadas, eles

diferentes provavelmente atributos terão e, potencialmente, até mesmo nomes diferentes e termos.

Decompondo um modelo tradicional

Figura 5-33

O diagrama de entidade pseudo na Figura 5-33 mostra uma possível abordagem para uma decomposição de "entidades iniciais" tradicionais (anti-

padrão) em vários contextos delimitadas (BCS). Nós temos que ter um modelo diferente para cada contexto limitada, mas em muitos casos (como

Figura 5-33), você tem o mesmo "conceito" da entidade em vários modelos, usando o mesmo nome da entidade, mas provavelmente com algum

diferentes atributos.

Neste exemplo, que estão dividindo entidades com base no que os atributos têm de ser compatíveis entre si e ao impacto para o outro.

Por exemplo, a Registrante classe de entidade em um hipotético ConferencesManagementBC pode ter dados pessoais como nome, endereço,

dados da empresa, e assim por diante. Porém, é provável que o atributo de "status" faz mais sentido dentro do Registrante classe de entidade de uma forma BC chamado, diferente por exemplo, OrderingBC, porque esse atributo deve ser consistente com a conferência RegisteredAttendees atributo.

Portanto, os limites BC também devem ser identificados com base na coerência entre os dados e quais atributos impacto outro

atributos e quais não têm impacto em todos. Por exemplo, se você alterar o requerente do Nome, que não afetará a conferência

atributos de registro.

Às vezes, você precisa ter atributos redundantes em diferentes contextos limitados (tentar minimizar isso). Nesses casos, você vai

tem que lidar e abraçar "eventual consistência ". Você também pode usar eventual consistência entre os diferentes agregados (conjunto consistente

de entidades).

Além disso, tendo um olhar para as relações necessárias entre as entidades (agrupando-os em agregados) é uma boa maneira de identificar BCs. Se

alguma área do modelo inicial é realmente isolada de outras áreas do potencial de aplicação, essa área deveria ser um

contexto limitada. Figura 5-34 ilustra este processo.

Cada modelo de contexto e de domínio limitado é uma visão diferente da mesma realidade (o domínio), mas para a utilização e finalidade diferente.

Para entender isso, não é uma metáfora famosa

de Eric Evans dizendo que o mundo (a realidade) é o

domínio e qualquer tipo de mapa-mundo é um BC diferente

com o seu próprio modelo de domínio.

Identificar Limitada Contextos

Ao projetar e implementar as entidades, também é

fundamental não ter um "anêmico-domain modelo "

(Anti-padrão) em DDD. As classes de entidade devem ter sua

própria lógica de domínio dentro dos métodos da classe entidade.

A implementação de entidades de domínio modelo usando

Tecnologia de desenvolvimento da Microsoft pode ser alcançado

através de diferentes formas, mas a maneira recomendada

pela Microsoft é usando POCO (Plain Old CLR Objects)

entidades (classes simples) que devem cumprir a

"Persistência ignorante" princípio (sem dependências

a partir deo

tecnologia). Em seguida, o modelo deve ser fracamente acoplado às tecnologias de infra-estrutura de persistência de dados como Microsoft Entity

Quadro e Code-First mapeamentos abordagem. Outras alternativas incluem diferentes O / RMs, como NHibernate, ou personalizado

se aproxima "do zero", baseado no ADO.NET simples. Mas, em qualquer caso, as dependências finais (entidades e repositório

contratos / interfaces) tem que estar dentro do modelo em vez de tecnologias de infra-estrutura. Essa é uma diferença crucial entre

Arquiteturas DDD camadas em comparação com arquiteturas em camadas regulares.

Figura 5-34

entidades se

para infra-estrutura

Implementar padrões de Domain-Driven Design e outras características com. NET

Ao aplicar Domain-Driven Design, cada camada geralmente implementar diferentes padrões como Entidade de Domínio, agregado,

Aggregate-Root, acoplamento fraco entre os agregados, Armazenamento agregado, Value-Object, Repository, Unidade de Trabalho, Serviço de

Factory, Domínio, eventos de Domínio, consistência eventual e assim por diante. (Para explicações detalhadas sobre esses padrões, por favor consulte o DDD

referências citadas abaixo.)