Software Público Brasileiro

<?xml version='1.0' encoding="utf-8"?>
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
   "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" []>
<chapter id="arquetipo">

	<title>Arquitetura</title>

	<section>
		<title>Estrutura</title>
		<para>
			Visando uma melhor modularização, o Demoiselle está dividido por funcionalidades. Isto significa que o framework
			não é monolítico, no qual todas as suas funcionalidades estão contidas em um único pacote. Aliás, esta estratégia não é
			a mais indicada, pois projetos com um propósito específico, que não necessitam de persistência ou interface Web, por
			exemplo, teriam dependências desnecessárias. Assim, o Demoiselle é separado em Core, Extensões e Componentes.
		</para>
		<!-- TODO: incluir um diagrama ilustrando a estrutura do framework -->
		<para>
			O Core do Demoiselle contém aquelas funcionalidades comuns a todas as extensões e aplicações. O core é simples,
			leve e formado majoritariamente por interfaces e poucas implementações. O Core é a base do framework, sem ele, as
			extensões e a própria aplicação não funcionariam.</para>
		<para>
			As Extensões, como o próprio nome sugere, estendem o Core com funcionalidades extras e bem específicas a um domínio ou
			tecnologia. Neste contexto, caso sua aplicação necessite de persistência com JPA, o framework fornecerá facilidades
			para você; contudo, estas funcionalidades não estão no Core. Para este propósito existem as extensões como a
			<literal>demoiselle-jpa</literal>, por exemplo. Cabe destacar que as extensões não possuem vida própria, 
			pois estão diretamente ligadas ao núcleo do framework, inclusive o ciclo de vida das extensões está 
			totalmente acoplado ao do Core.
		</para>
		<para>
			Já os Componentes são artefatos separados e que, portanto, não são dependentes diretamente do Core. Aliás, os
			Componentes podem até mesmo existir sem referenciar o Core. Desta forma, o seu ciclo de vida é totalmente
			independente do Core e Extensões. Um componente não precisa, necessariamente, estender o comportamento do Core, mas
			permitir disponibilizar novas funcionalidades ao usuário. Outra diferença importante é que, diferente de Core e
			Extensões, os Componentes não necessariamente são aderentes a alguma especificação. Um exemplo é o 
			<literal>demoiselle-validation</literal>.
		</para>
	</section>

	<section>
		<title>Pacote Internal</title>
		<para>
			As boas práticas de programação nos alertam para que nunca sejamos dependentes de implementações, mas sempre de
			interfaces ou, como alguns costumam dizer, <quote>depender de contratos</quote>.
			As interfaces existem para isto: definem um contrato, enquanto as implementações deste contrato ficam à parte, de
			preferência, distante do programador da aplicação. O mecanismo de injeção de dependência fortalece ainda mais esta
			ideia. Sua aplicação precisará apenas depender das interfaces que o Demoiselle provê. A implementação específica será
			injetada automaticamente pelo CDI.
		</para>
		<tip>
			<para>
				As classes do pacote <literal>internal</literal> nunca devem ser referenciadas pela sua aplicação!
			</para>
		</tip>
		<para>
			Qual o motivo de toda esta explicação? Os programadores mais curiosos irão encontrar classes do framework que estão
			inseridas no pacote <literal>internal</literal>. 
			Cabe alertar que as classes aí contidas não devem ser usadas diretamente pela aplicação, caso contrário, você
			estará acoplando-a com a implementação interna do framework, que pode sofrer mudanças sem aviso prévio. A equipe do
			Demoiselle possui atenção especial quanto às suas interfaces (contratos) e não irá modificá-las sem antes tornar
			públicas as mudanças. Contudo, tudo que consta no pacote
			<literal>internal</literal>
			pode sofrer mudanças repentinas. Isto significa que sua aplicação pode deixar de funcionar de uma versão para outra
			caso você esteja usando diretamente classes internas.
		</para>
	</section>

	<section>
		<title>Arquitetura das aplicações</title>
		<para>
			É importante reforçar que o Demoiselle não obriga nenhum tipo de arquitetura para as aplicações, que podem ser
			constituídas por quantas camadas forem necessárias. Contudo, é prudente não exagerar! Para quem não sabe por onde
			começar, sugerimos uma arquitetura e padrões largamente utilizados pelo mercado, de forma a facilitar a manutenção e
			para melhor modularização de seu projeto.
		</para>
		<para>
			Usualmente, as aplicações são constituídas por pelo menos três camadas, desta forma é comum separar as lógicas de
			apresentação, regras de negócio e persistência. O Demoiselle já fornece estereótipos que visam tornar esta 
			separação mais clara, respectivamente:
			<literal>@ViewController</literal>, <literal>@BusinessController</literal> e <literal>@PersistenceController</literal>. 
			Maiores detalhes sobre cada anotação desta serão dados no decorrer desta documentação.
		</para>
		<!-- TODO: explicar melhor cada um dos estereótipos, se possível exemplificando com códigos -->
		<para>
			Cabe destacar que estamos falando de uma macro-visão arquitetural. Cada camada desta pode ser organizada
			internamente da melhor forma possível, ou conforme os padrões vigentes no mercado. Para uma aplicação Swing, por
			exemplo, o padrão de projeto <emphasis>Presentation Model</emphasis>
			é bastante indicado e pode ser adotado em aplicações nesta plataforma. Para aplicações Web, os frameworks
			especialistas geralmente aplicam o padrão MVC (Model/View/Controller).
		</para>
	</section>

</chapter>