Projeto EAGLE

Apresentação

Quando foi que perdemos o com.passo?

Aonde estão as chaves?

De minha primeira Grande Visão

A Informação em Perspectiva

O Projeto EAGLE e os seus Dados

Contexto, premissas e principais artefatos

Principais processos e responsabilidades

Principais Axiomas e Postulados Estruturais

Sobre scripts, schemas e mapeamento

Principais Axiomas e Postulados Funcionais

O Projeto EAGLE e os Databases

Índice

Sobre scripts, schemas e mapeamento

Fora do “silo” corporativo mais diretamente relacionado ao gerenciamento operacional diário de banco de dados, costuma haver uma certa confusão entre os termos “script” e “schema”. Analistas, desenvolvedores e testers geralmente delegam o seu significado ao contexto em que os mesmos são utilizados.

Em pról da clara – e “unívoca” – comunicação entre todos os membros das diversas equipes de uma forma ou de outra relacionadas à área de TI, reforçamos aqui o seu significado original e uso adequado e, portanto, recomendado.

Schema significa forma ou, mais genericamente, plano; podendo se referir a modelos e diagramas [gráficos] (aqui).

  • XML Schema define a estrutura e o conteúdo de documentos XML (aqui).
  • DB Schema define a estrutura e os elementos de um DB; em DB relacionais, define tables, fields, relationships, views, indexes, procedures, functions, triggers, XML schemas, entre outros. Geralmente são armazenados em dicionário de dados e, embora o termo se refira a uma linguagem textual, é frequentemente utilizado para se referir à representação gráfica da estrutura do DB (aqui).

Scripts são pequenos programas, escritos para um interpretador de comandos ou linguagem de scripts. Ou seja, os mesmos não são compilados, mas requerem um “contexto” apropriado, para que possam ser devidamente interpretados (os seus comandos, instruções) e executados. (aqui e aqui)

  • Arquivos Batch (.bat) são executados no contexto do sistema operacional.
  • Navegadores web (web browsers, IE – Internet Explorer, Google Chrome, Firefox etc.) fornecem o contexto para a execução de scripts escritos em várias linguagens, como HTML, XML, CSS, Javascript, Ajax e jQuery. (client-side) (aqui)
  • Servidores web fornecem contexto para a execução de scripts escritos em outras linguagens, como PERL, PHP, ASP.NET e Java (server-side) (aqui)
  • RDBMS (Oracle, Sql Server, MySql etc) fornecem contexto para a execução de scripts SQL – Structured Query Language (aqui), que contempla tanto a definição estrutural dos dados (aqui) como de sua manipulação (aqui).
    • Estes contextos, todavia, são proprietários (vendor tightly coupled, dependent); ou seja, cada um destes contextos só “entendem” o seu próprio “dialeto” SQL.
    • Por isso, o EAGLE – a fim de garantir as requeridas flexibilidade, transparência, facilidade e qualidade – deverá encapsular tais funcionalidades, isolando-as de seu contexto central, agnóstico (vendor independent, loosely coupled). E é aí que entra, mais uma vez, o conceito de framework: iremos oferecer uma implementação default [SQL Server], e uma ou mais opções nativas (built in); ou seja, devidamente implementadas e testadas. Além disso, o usuário poderá optar por sua própria implementação (não-nativa), através do conceito/pattern “plug in”, muito provavelmente no contexto/ferramenta do DGF/DHTD.
      • Note que existem DB especificamente voltados para a plataformas móveis (mobile: tablets, smart phones, …) como SqlCeServer, SqLite, etc.
      • E como “de perto ninguém é normal”, note ainda que cada uma dessas opções também se sub-dividem, o que deve ser igualmente previsto, modelado e implementado apropriadamente. SQL Server 2008, 2010, 2012… Oracle 9, 11g… SQLite 3.4.2, 3.5.0, 3.7.17… Ou seja, “o buraco é mais embaixo”.

ORM – Object-Relational Mapping.

ORM é uma técnica de programação que provê uma camada de abstração lógica que, como diz o nome, mapeia o modelo relacional dos databases para o modelo orientado a objeto, e vice-versa. E é aqui [também] que “a vaca torce o rabo”, mais uma vez…

worldGrade

No início era o Hibernate (para Java); depois veio o NHibernate (“portado” para o .NET); então surgiram o EF – Entity Framework, o Unity, o MEF – Microsoft Extensibility Framework etc. [Para falar só da plataforma Microsoft]

Existem, ainda, variações desta “técnica”, para “facilitar” a vida dos desenvolvedores [ou melhor, dos projetos dos quais participam], e confundir a sua cabeça. Em tese, a sua lógica, aplicabilidade e existência é facilmente compreensível e justificável:

blogs

orm approach decision

Code first

  • Very popular because hardcore programmers don’t like any kind of designers and defining mapping in EDMX xml is too complex.
  • Full control over the code (no autogenerated code which is hard to modify).
  • General expectation is that you do not bother with DB. DB is just a storage with no logic. EF will handle creation and you don’t want to know how it do the job.
  • Manual changes to database will be most probably lost because your code defines the database.

Database first

  • Very popular if you have DB designed by DBAs, developed separately or if you have existing DB.
  • You will let EF create entities for you and after modification of mapping you will generate POCO entities.
  • If you want additional features in POCO entities you must either T4 modify template or use partial classes.
  • Manual changes to the database are possible because the database defines your domain model. You can always update model from database (this feature works quite good).
  • I often use this together VS Database projects (only Premium and Ultimate version).

Model first

  • IMHO popular if you are designer fan (= you don’t like writing code or SQL).
  • You will “draw” your model and let workflow to generate your database script and T4 template to generate yout POCO entities. You will lose part of control on both your entities and database but for small easy projects you will be very productive.
  • If you want additional features in POCO entities you must either T4 modify template or use partial classes.
  • Manual changes to database will be most probably lost because your model defines the database. This works better if you have Database generation power pack installed. It will allow you updating database schema (instead of recreating) or updating database projects in VS.

[ fonte ]

↑ Topo ↑
 
Anúncios

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: