· 6 years ago · Jan 14, 2020, 05:46 PM
1APONTAMENTOS DAE TEÓRICA
2
3 Teorema de Jackson
4 ESB - Enterprise Service Bus
5
6 Padrão arquitectural das 3 camadas - presentational, logic, data
7
8 Layer - camada lógica
9 Tier - camada física
10
11 -------
12 | PLL | Web/Mobile, CLI -> comunicam só com a camada abaixo, Verificação de inputs
13 |^^|vv| Service Layer
14 | BLL | Business Logic Layer
15 | DAL | Esta camada faz a ligação entre a BLL e as fontes de dados
16 -------
17 | |
18 -----> DBs, Cloud, Ficheiros
19
20 Aplicações clientes de base de dados (comunicavam directamente com a BD). Migrar de SQL para NoSQL (por exemplo) seria impossível pois seria necessário refazer toda a sintaxe por cada aplicação
21
22 No modelo das 3 camadas, é só necessário alterar o componente para que todas a as aplicações que consomem/usem aquela lógica de negócio o façam correctamente
23
24 PADRÃO ARQUITECTURAL
25
26 Modelo das N-camadas (camadas horizontais + camadas verticais)
27
28 Serviços de Apresentação - Regras de Negócios - Serviços de Dados
29
30 Servidor aplicacional - componentes da lógica de negócio
31
32 Lógicas de negócio espalhadas por vários componentes = dificuldades de actualização e manutenção do código (Web, Mobile App, diferentes pontos de entrada)
33
34 SIFARMA: sistema que gere todos os medicamentos do Infarmed. Se a lógica de negócio estiver dependente de uma base de dados e essa BD só funcionar num servidor específico, ficamos limitados a esse servidor em particular (o servidor vai-se desactualizar ao longo do tempo)
35
36 Testes teóricos: perguntas "O que é & Diga um exemplo"
37
38 1ª Camada: Lógica de Apresentação
39 > Processa Dados
40 > Apresenta Dados
41 > Solicita Dados mediante uma interacção do utilizador
42 > Tratamento de inputs
43 > Quanto menos lógicas estiverem na camada de apresentação mais fácil é implementar o multi-canal (web,mobile, aplicação, cliente)
44
45 2ª Camada: Lógica de Negócios (brainpower)
46 > Recebe, interpreta o pedido, realiza as tarefas necessárias para atender o pedido, trata a info e responde adequadamente
47
48 [x] Class PessoaBLL {
49 AcessoDados ad = new AcessoDados();
50 ad.ExecutaSelect("SELECT * FROM STUDENT") // /!\ estamos a revelar a estrutura da nossa BD /!\
51 }
52
53 Class DAL {
54 Insert(){}
55 Update(){}
56 Delete(){}
57 FindByID(){}
58 }
59
60 BaseDAL { // helper
61 AbrirConexao(){}
62 ExecutarQuery(){}
63 ExecutarUpdate(){}
64 FindByID(){}
65 }
66
67 Para ser aplicação empresarial não é necessário ter todos os atributos do slide APLICAÇÃO EMPRESARIAL, basta um par deles
68
69 DAL não recebem strings de SQL como argumentos de métodos para não revelar o funcionamento interno da BD e não desdobrar o código por mais do que uma camada
70
71 Para cada camada há um conjunto de padrões
72
73 Exemplo "Facebook"
74 - Aceder ao Facebook carrega toda a informação ou pequenos excertos de informação? 2ª opção
75 - Lazy Loading (Permite poupar em tempos de espera, hardware, dados, cloud, processamento etc) / Eager Loading: carrega-se tudo de antemão
76
77 Application Data Loading (Lazy/Eager/etc)
78 - Reconhecer nas frameworks onde é que se afina o tipo de loading para uma melhor eficiência de recursos (aplicações empresariais podem usar uma grande quantidade de dados, importante optimizar)
79
80 Empresas já não têm servidores, têm "data centers". O hardware deslocalizou-se para os grandes fornecedores de armazenamento e web hosting
81
82 Padrões Arquitecturais: 3 Camadas, M-V-C, Iterator, Flyweight, Composite, Decorator, Singleton (uma classe que só pode ter uma instância, para sincronizar contadores e etc),
83 - nascem da necessidade e só depois passam a standard, dada a sua utilidade
84 - Iteradores nascem após um período de utilização de ciclos 'for', para melhor eficiência na utilização de colecções
85 - "Gang of Four" Design Patterns
86 - "A design pattern names, abstracts, and identifies key aspects of a common design structure that make it useful for creating a reusable design-oriented object"
87 - Necessidade de equilibrar a rigidez dos padrões arquitecturais com as necessidades de desenvolvimento de aplicações
88 - agnósticos (não se restringem a um S.O., linguagens de programação, filosofia (open-source, paid)
89 - muitas vezes os padrões são simples demais para cobrir todas as necessidades de desenvolvimento de software
90 -padrões usam-se sempre para criar aplicações empresariais, aplicações escaláveis
91
92 ORM: Object-Relational Mapping
93
94 Padrões de Acesso a Dados / Data Access Patterns
95
96 Formas de representar entidades de negócio: Class, Tabela, JSON, XML, Enum(?)
97
98 DAL -> Table Data Gateway
99
100 Cada Entity (ex: studentBean) tem uma referência para a sua Table Data Gateway (studentGateway)
101
102 BLL & DAL estão no mesmo servidor aplicacional
103
104 Pedidos entram no Table Data Gateway e acedem a outro contexto. Tratam a resposta do pedido e devolve à BLL. Um TDG é um singleton, existe 1 por cada tabela e trata todos os pedidos relacionados com a dita tabela
105
106 Active Records: Lógica de negócios e acesso a dados só num componente. Não existe a filosofia das 3 camadas. Dados não são independentes da lógica de negócio. No caso em que de queiramos alterar a fonte de dados (BD) temos de alterar em todos os Active Records (BLL+DAL) pois a BLL está interligada com a DAL. Oferece rapidez de desenvolvimento, facilidade de aceder dentro do mesmo componente a métodos que acabei de computar.
107
108 Data Mapper:
109
110 |---------| |------------------| |----|
111 | Student | <------| StudentDataMapper| ------->| BD |
112 |---------| |------------------| |----|
113
114 No StudentDataMapper só existe a lógica de negócio, nada mais. Como só tem a lógica de negócio, é possível reutilizar estas lógica para outro projecto. Pode funcionar também como conversor de dados entre entidades e a BD, se houver uma dessincronização entre o modelo do domínio e a BD, para garantir a consistência e funcionamento (StudentLegacy, StudentAGCP, StudentIntranet). PLL chama o bean para alterar um Student e comunica ao StudentDataMapper o ID em questão para que ele verifique as alterações e as reflicta na BD (problema: salta a camada BLL, PLL a comunicar com o DAL directamente). Para evitar isto pode-se criar um DataMapper mais de alto nível que não se sabe ligar as dados directamente, é o elo de ligação entre a PLL e a DAL
115
116 Padrões de Acesso a Dados
117 - IdentityMap: Mapa de Identidades
118 - UnitOfWork: Unidade de trabalho
119 - LazyLoad: Carregamento preguiçoso
120
121 Por cada query, não é exequível estar sempre a aceder directamente à BD, é são necessários padrões que maximizem a eficácia/eficiência dos acessos (caches para guardar dados comummente acedidos). Funcionamento "happy path" de um padrão: quando os dados estão logo disponíveis na cache. Mudanças de contexto são onerosas em termos de tempo dispendido para realizar a operação
122
123 UnitOfWork: Imaginem que estão a comprar coisas numa loja online. Estão indecisos, vão pondo no carrinho, retiram do carrinho, vão trocando, alterando cor/quantidade/etc. Vão manipulando o carrinho. Mesmo num site moderno o carrinho de compras já é guardado na BD do website. O UnitOfWork regista os objectos que foram afectados por uma transacção e coordena a escrita de alterações e a resolução de problemas de acesso a dados. Cria uma "Big Transaction" e executa tudo de uma vez, só há uma ligação
124
125 LazyLoad (4 modos)
126 > Lazy initialization: não dar toda a rede de objectos associada a mim (objecto). Lazy load permite um mais ágil funcionamento da aplicação. Necessário ter o domínio do objecto no servidor. Lazy initialization é dar um objecto vazio/alguns atributos e dou-te os getters/setters dos atributos e neles é que vou verificar se já carreguei essa informação. Dá-se este nome porque é possível ter muitos atributos mas só alguns é que eu carrego quando acedo ao estudante. Os outros, no meu getter ou setter (mais no getter), quando alguém quer saber algum detalhe adicional, só aí é que o meu Get vai ver se está a null, então é necessário aceder à BD para ir buscar a INFO que até agora não tinha sido carregado. Vai-se carregando os atributos dos objectos consoante os pedidos
127 > Ghost - Assim que se acede a um atributo de um objecto, todo o objecto é imediatamente carregado. Se eu preciso de alguma info de uma UC, p. ex., o Ghost vai carregar toda a UC, não faz um carregamento incremental à medida dos pedidos
128 - Virtual Proxy - não é o próprio objecto que se carrega, como nos exemplos acima, é alguém que os manipula. Servidor de proxy: em vez de toda a gente aceder ao mesmo server, é alguém que procura o objecto e o disponibiliza. Rede de objectos é toda carregada como proxy, mas sem informação associada aos atributos (espécie de esqueleto dos objectos está carregada mas a info não). Os objectos não estão lá, o que está lá são os procuradores do objecto (VPUC - sabe onde é que realmente está a UC na memória, e como hierarquicamente também é uma UC, se for acedida a proxy vai dizer onde é que o objecto está na memória). Ao haver um getUC, vai devolver a referência de memória da UC para que o Student possa ir buscar o objecto
129 - Value holder - Também não é o próprio objecto que é acedido, não se acede ao objecto real, é um objecto que guarda os valores do objecto em questão para ocultar a estrutura do código (uma espécie de DTO)
130 * Lazy initialization e Ghost dão acesso ao objecto completo
131 * Virtual Proxy e Value Holder não dão acesso ao objecto em si
132
133 Unit Of Work: recolher uma série de acções que vão sendo feitas sobre determinado objecto e depois quando houver uma commit aí sim fazer uma big Transaction
134 - Caller Registration: registration é o registo na UnitOfWork de quem é que está a fazer coisas. Quem é que avisa a UnitOfWork de que eu fiz uma alteração no carrinho? Para depois se saber o que é que a UnitOfWork tem de enviar para a BD no final. Caller é a aplicação-cliente. Se eu altero o credit limit do Customer, tenho de comunicar à UnitOfWork isto mesmo (register dirty(a customer) - "dirty" significa que algo mudou e tem de ser comunicado à BD). Em Caller Registration é o Client que comunica as alterações que a UnitOfWork tem de comunicar à BD
135 - Object Registration: é o próprio objecto que avisa a UnitOfWork que foi criado/alterado. No modelo do Caller o objecto é "puro", não tem métodos para comunicar com a UnitOfWork. Se cada objecto souber cuidar de si, então o Client não necessita de avisar a UnitOfWork da criação/alteração de objectos
136 - UnitOfWork Controller: não é só uma pessoa que está à espera de que a avisem, tem todas as ferramentas necessárias para verificar se houve alguma criação/alteração de objectos. A UnitOfWork está implementada no funcionamento do aplicação e todo o fluxo de trabalho passa por ela, sendo ela quem tem a responsabilidade de registar as alterações que devem ser enviadas para a BD
137
138 Padrões estrututais de ORM
139
140 Identity Field: campo ID. Quando se põe o @Id em JavaEE, é o padrão Identity Field que está em acção.
141
142 Chave com significado: neste caso a chave tem alguma relação com o mundo real(ex: NIF)
143 Chave sem significado: Global Unique Identifier (GUID)
144
145 Foreign Key Mapping: Mapear associações entre objectos para uma chave estrangeira que os relacione
146
147 Association Table Mapping: tabela do meio com chaves extranjeiras para as tabelas que, por associação, estão relacionadas com a associação
148
149 BLOB: guarda a informação numa coluna, ocultar informação, não querer pôr a informação numa tabela
150 - vantagens: mais eficientes
151 - desvantagens: impossível descodificar,
152
153 CLOB:
154 --vantagens: fácil perceber o que é que está armazenado, se houver uma evolução do objecto (ex: acrescentar atributos) é possível actualizar os CLOB, mais lento, ocupa mais espaço
155
156 Mapeamento de Heranças
157 - Single Table Inheritance: esquema por omissão do JavaEE. Vantagens: não tem joins, funcionamento simples. Desvantagens: muitos campos vazios (uso ineficiente de memória, má optimização). Se eu tiver múltiplas aplicações a usar a mesma tabela irá haver um "engarrafamento" no acesso à tabela
158 - Class Table Inheritance: Vantagem: não há nulls pois todos os objectos estão numa hierarquia. Desvantagem: necessário fazer joins frequentemente para obter informação. No caso de haver aplicações penduradas na BD não é possível fazer alterações no modelo do domínio
159 - Concrete Table Inheritance: Meio termo entre os 2 anteriores. Vantagem: Sem "bottleneck". todas as tabelas têm toda a informação. Se eu quero um Student, só é necessário ir à tabela Student, sem joins. Desvantagem: Mais espaço em memória
160
161 1.
162 a) Arquitectura de Software. Praticamente impossível alterar uma vez estando em funcionamento.
163 b)
164 i. Aruitectura das 3 camdas em que a camada de apresentação só interagem com a lógica de negócio e esta só interage com a camada de acesso a dados, monolítico, P-2-P ( todos os clientes da minha arquitectura são P2P)
165 ii. Necessário perceber as reais necessidades do projecto o quanto antes para depois implementar a melhor arquitectura de software para o problema em questão
166
167 (importante: Características de uma aplicação empresarial)
168
169 3. O que é que não está tão correcto nesta frase? Camada de acesso a dados não acede apenas à BD, também à Cloud e ficheiros, etc
170
171 4. Se eu estiver a alterar a ficha de um estudante, usar a UnitOfWork para ir guardando as alterações e, após o commit, realizar a transação para guardar os dados na BD
172
173------------------------
174Segunda parte da matéria
175------------------------
176
177 Domain Model
178 Table Module
179
180Esforço de
181Implementação
182 | /Table / Domain
183 | /Module __/ Model
184 | / ____/
185 | / ----/
186 |/_______________
187
188 Complexidade do modelo de domínio
189
190 Domain Model mais eficiente para pequenas operações CRUD, mas oneroso na transformação entre classes Java/DTOs/armazenamento na BD, para realizar alterações na BD é necessário angariar objecto a objecto e depois transformar para logo poder enviar as alterações para a BD. Mais custoso na Implementação (hierarquias, polimorfismo, ORM(ex: many to many) lógica de negócio)
191
192 Table Module há um DataSet, tem um conjunto de dados colunizados e tenho de ir à procura deles, bom para mexer em muitos registos simultaneamente
193
194 Exemplo MS Access: tinha um Table Module, gerava operações de CRUD sobre a BD
195
196 Service Layer: granularidade baixa, não há coisas muito específicas, grande overhead na comunicação, as APIs não devolvem o preço de um só produto, mandam p. ex. os preços de toda a categoria, pois a maior parte do tempo perde-se no estabelecimento da ligação
197
198 Marshalling de ligações
199 Marshalling/Unmarshalling de DTOs
200
201 Tornar independente a lógica de negócio da service layer (separar os Beans dos HttpControllers)
202
203 PADRÕES DE LÓGICA DE APRESENTAÇÃO
204 ´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´´
205 - MVC (não era da web, MVVM)
206 - Front Controller
207 - Page Controller
208 - Transform View
209 - Two-step Transform (não é só da Web)
210 - Template View
211 <notifyView
212 ---------------------------------------
213 | MVC queryState> |
214 | |
215 | pedidos |
216 View <-------> Controller <--------> Model
217 user
218 gestures
219
220 Front Controller: Controlador para todas as páginas, estatísticas, funções de seguranças, verificações de segurança/sessão, estado de sessão do cliente/servidor. Está na PLL. Front controller evita a repetição de código, facilita a manutenção e evolução do website.
221
222 Page Controller: Controlador associado a uma única página, sabe lidar com os dados só da view, está acoplado à view (MVVM). Controlador acoplado aquela vista e àquele modelo. Só controla uma única página.
223
224 Transform View/Template View: sempre usados por todas as frameworks
225 Transform View: eu quero renderizar uma página em HTML. Ora, eu sou um padrão cujo propósito é permitir que tu tenhas um código aqui no meio que vai buscar código que não está numa linguagem de vista e o transforma numa destas linguagens para adaptá-lo a uma view
226 ---------- ------------------
227 | Modelo | <--------- | Transform View |-----------> XML, JSON, HTML..
228 ---------- |----------------|
229 | | | |
230 | | | |
231 ---------- ------------------
232 Template View: é a minha própria linguagem de vista que invoca os componentes dinamicamente para renderizar os componentes a posteriori. Vai misturar linguagem de vista com linguagem de template view. Posso-me referir a outros templates view dentro do meu template view (p. ex. um template view em Java que vai ser processado quando se invocar o JSF) vantagem: fica mais limpo pois a invocação de métodos evita a utilização de scripts complexos no meio do código da vista. Cada tag é um mini TransformView que vai gerar o HTML final. Vue é um conjunto de tags que não pertence ao HTML onde há um servidor que pré-processa e renderiza o HTML gerado.
233 ---------- ------------------
234 | Modelo | <--------- | Template View |-----------> DataTables, scripts, tags (<table> .. </table>)
235 ---------- |----------------|
236 | | | |
237 | | | |
238 ---------- ------------------
239
240 Two-Step View:
241 ---------- -----------------------
242 | User | <--------- | 1st Step Transform |
243 ---------- |---------------------| Agarro a informação do modelo sem informação da lógica de apresentação
244 | | | | e transformo-a num código abstracto
245 | | | |
246 ---------- -----------------------
247 THEN
248 ---------- -----------------------
249 | | <--------- | 2st Step Transform | Transformo o código gerado numa linguagem de vista concreta pronto a ser executado
250 | | |---------------------|
251 | | | |
252 | | | |
253 ---------- -----------------------
254 FINALLY
255 ----------
256 | HTML | Ou Linguagem de layout do Android, do Swift.. Gera as tags necessárias para cada vista
257 | HTML | VANTAGEM: 1 única base de código para qualquer número de aplicações. O 2nd Step Transform adapta para qualquer linguagem de apresentação de dados
258 ---------- DESVANTAGEM: Não chega ao refinamento em termos de desempenho e controlo do dispositivo de hardware das aplicações nativas, pelo que algumas empresas preferem desenvolver várias aplicações nativas (Futuramente: Flutter, ReactJS)
259
260 Concorrência a dados: múltiplos contextos de execução (processos, threads) a acederem aos mesmos dados no mesmo intervalo de tempo.
261
262 Hierarquia das transacções: |
263 | System Transaction 1
264 Business Transactions |
265 | System Transaction 2
266
267 Padrões de acesso a dados:
268
269
270 PADRÕES DE CONCORRÊNCIA
271
272 - Leituras Inconsistentes: A e B fazem uma leitura. A pode realizar alterações com base em informação que vai ser imediatamente alterada por B, acontecendo uma leitura inconsistente com a realidade. Ler informação que entretanto já foi alterada (está inconsistente)
273 - Há necessidade de haver concorrência a dados para ter sistemas mais eficientes (problemas de convivência)
274 - Severidade dos erros gerados pela concorrência (problemas de convivência)
275 - Ter atenção ao contexto para decidir que padrões de concorrência usar
276 - Formas de controlar a concorrência com isolamento, imutabilidade
277 - Optimistic Lock vs Pessimistic Lock (locks simplistas)
278 - Solução para o problema do optimistic (alterações são perdidas pois alguém alterou os dados antes de submetermos os novos dados): versionamento (VCS) vai criando versões de objectos à medida que vão sendo editados para perceber quando há alterações aos atributos desse objecto, se a versão que lá está é a mesma versão do ponto de partida dos contextos. Dei-vos a versão 50, pelo que se quiserem submeter alterações, a versão de partida terá de ser a 50. Versionamento surge para resolver os problemas que o lock optimista criou.
279 - Problemas dos bloqueios pessimistas: não há acessos concorrente, apenas um contexto acede de cada vez aos dados.
280 - Soluções do bloqueio pessimista: implementar timeouts para evitar bloqueios por temp indefinido por parte de um contexto
281 - Soluções simplistas também trazem problemas inerentes às suas condicionantes
282 - Read-lock: recurso bloqueado para leitura (normalmente)
283 - Exclusive read-lock: eu vou lá, bloqueio para leitura, não permito que mais ninguém leia/escreva no recurso
284 - Shared read-lock: partilhável, estou a ler o recurso mas permito que os demais o leiam
285 - Pessimistic-read é shared
286 - Enquanto houver alguém que tenha um pessimistic-read num recurso, ninguém poderá alterar o recurso
287 - Write-lock: enquanto escrevo ninguém pode escrever nem ler nesta entidade, para evitar leituras Inconsistentes
288 - Exemplo de editores de texto multi-utilizadores, em que há vários a escrever no mesmo documento. Possibilidade de disponibilizar links de visualização
289 - Coarse grain lock: muitas vezes eu quero bloquear não só um recurso mas um conjuntos deles. Ou eu crio um contentor imaginário e aplico um lock a tudo dentro do lock
290 - Root lock: bloqueio num único sítio e garanto que ninguém pode aceder a todos os recursos afectados por aquele lock raiz (exemplo: só se podem aceder aos sítios acedendo à prateleira onde está o livro)
291 - Shared lock: Indíce de versóes de locks. Quando outros contextos tentarem aceder, exemplo um exclusive pessimistic lock, não vai poder aceder ao livro nem à prateleira, porque para mexer no livro está a dar lock à prateleira também.
292 - Documentos, em temros de contabilidade, uma factura quando é emitida tenho duas hipóteses para cancelar, ou emito uma nota de crédito ou anulo a factura (necessário contactar a autoridade tributária). Se eu já enviei a factura ao cliente então tenho de emitir mesmo uma nota de crédito. Não posso alterar a morada fiscal de uma factura já emitida. Quando bloqueio um cliente para alterá-lo, eu não devo bloquear todos os documentos afectos àquele cliente. Devo criar uma versão nova dele e afectar todos os documentos a este cliente. Não devia alterar as facturas antigas pois é um facto já sucedido e reflecte uma realidade passada mas que tem de ficar registada.
293
294 | Remote Facade
295 |
296 | Data Transfer Object
297
298 Alterar interfaces remotas: "A vossa vida vai ser criar API, interfaces para interagir. Cuidado com as alterações de parâmetros que podem rebentar com endpoints"v
299
300 ----------
301 | Client |
302 | App |
303 ----------
304 | |
305 | | DTO / XML / JSON / Binário
306 | |
307 ------------------
308 | Service Layer |
309 |----------------|
310 | |v|v| |^|^| |
311 |----------------|
312 | Bean |
313 |----------------|
314 | |v|v| |^|^| |
315 |----------------|
316 | Entities |
317 ------------------
318
319 -------------------------------------
320 | Assemblador (pack & unpack DTOs) |
321 |-----------------------------------|
322 | createAthlete(AthleteDTO dto) |
323 | updateAthlete(params) |
324 | createAthleteDTO(Athlete athlete) |
325 | updateAthleteDTO(params) |
326 -------------------------------------
327
328 ESB - orienta mensages e encaminha para o destinho
329 Mini-assembler
330
331 ESB com vários tópicos, componentes com várias subscrições
332
333 Componentes intermédios que façam a tradução do protocolo que os componentes entendam para o protocolo do ESB
334
335 Formatos de texto podem ser processados sem necessidade de conversão
336
337
338 PREPARAÇÃO TESTE TEÓRICO 2
339
340 1.
341 a) Decisões? Se eu ponho lá muita ou pouca lógica de negócio. Segurança e controlo transacional. Quanta lógica de negócio? Serice Layer: vários componentes que fornecem vários acessos a informação. @RolesAllowed. A API consegue ter acesso à sessão do utilizador, pelo que é possível estabelecer protocolos de segurança para cada nível de autenticação na aplicação. No nosso projecto, a API delega praticamente tudo para os Beans.
342
343 P: Describe and exemplify 2 of the most common strategies for distributing objects within an enterprise application: Cliente-Servidor (Servidor Web & Servidor Aplicacional)
344
345 P: Which factors influence the choice between concurrency solutions based on optimistic and pessimistic-locking? Se eu tiver muita probabilidade de ter problemas e o impacto desses problemas for muito alto (risco), usa-se optimistic, pois muito raramente vamos ter problemas, então vamos usar uma abordagem optimista pois verifica-se que raramente há problemas. Se eu tiver muita probabilidade de erros o que é que posso fazer para minimizar isto? (Exemplos da reserva de artigos/bilhetes nos carrinhos de compra)
346
347 DAE_FREQ2_16JAN18
348 Identifique 2 situações onde é quase inevitável distribuir/seprar uma aplicação empresarial por mais do que um processo/nó de processamento:
349 - Quando o servidor aplicacional tem uma carga muito superior à do servidor web
350 - É muito provavel ter varis aplicações a aceder à mesma base de dados
351
352 Padrão DTO com Assemblador
353
354 Como resolver problemas de concorrência sem locking? Isolamento e mutabilidade
355
356 Exemplificar um deadlock e dizer como resolver: timeout?
357
358 Explicar a diferença entre um shared lock e um root lock no conjunto Coarse-Grained lock: root lock de raiz para bloquear o acesso ao objecto