Este post é a continuação da descrição da camada de interface, da série sobre produtividade. No post anterior, mencionei a criação de uma DSL específica para a construção dos elementos de interface e o uso de layouts baseados em XSLT para transformar a DSL + Dados para o HTML final.

O último componente desta estrutura de interface é o próprio controller. Neste são executadas as ações que vão fazer uso dos serviços de domínio. Na minha visão, controllers devem ser bastante simples de construir e manter. Assim, eu utilizo um BaseController, que integrado à ViewEngine específica, encapsula todo o processo de execução de ações e geração do esqueleto do retorno, ficando somente à cargo do desenvolvedor a criação das rotinas de preenchimento do DataIsland e do chamada a regras de negócio.

A exemplo do que é feito nos frameworks MVC, as ações são decoradas para retorno de Html ou Xml puro. E utilizando uma biblioteca javascript específica, pode-se criar uma metalinguagem para, por exemplo, preencher uma área da tela, redirecionar para um outro endereço ou mostrar uma mensagem. Assim, da própria ação, fica super simples para se coordenar o que se quer fazer. Abaixo, um exemplo de controller da tela de login.

public class LoginController : BaseController {

[XmlResult]
public ViewResult Login(string login, string senha) {
var result = Agent.Login(login, senha, SessionID);
var address = HttpContext.Current.Request.UrlReferrer.Query;
if (result.LoginResult != LoginResult.Succeeded)
return CancelAction(“Login inválido”);

FormsAuthentication.SetAuthCookie(login, false);
SendRedirect(address);
return View();
}
}

Do lado do cliente, esta ação é chamada com um “onclick=’’Execute(Login)”’. Com estes facilitadores, utilizar AJAX é transparente para o desenvolvedor, e toda a lógica de controle da tela fica automatizada. O único trabalho é descrever a tela na DSL e fazer a chamada às camadas de serviço nos ações dos Controllers. A ViewEngine em conjunto com as bibliotecas javascript fazem todo o trabalho de wiring, execução de chamadas e controle de erros.

Além do suporte às ações, o controller de base também possui um suporte à carga de dados. Um grande efeito colateral de uma orientação a objeto na camada de domínio é que para se mostrar consultas e resultados em tela, é necessário abrir e navegar por um grande número de instâncias em memória. Isto é um problema para desempenho, pois dependendo da profundidade da árvore que se navega, o acesso pode ficar inviável. A maneira que o framework resolve isto é indo direto ao banco para consultas pesadas, de detalhamento ou de listas. O elemento de dados (também conhecido como DataIsland) possui métodos apoio para executar consultas (views) em um formato especialmente definido, preenchendo-o com o XML resultante. O exemplo a seguir ilustra isto:

protected override void DoFillDataIsland(DataIsland dataIsland, int page) {
dataIsland.CreateNameValueItemList(“Projects”, CurrentUser.AllowedProjects, PNP.Name, PNP.Id, false);
dataIsland.GetFormItem(“Filter”).Add(PN.Project, filterProject);
dataIsland.CreateListFromView(ListName, page, Filter.Criteria, GetFilterDescription(), OrderBy);
base.DoFillDataIsland(dataIsland, page);
}

Neste exemplo, é criada uma lista de Name/Value para uso em uma combobox a partir de uma coleção de projetos. Logo a seguir, é definida uma variável no DataIsland que vai ser usado para se definir qual o projeto selecionado na combobox. Finalmente, é criada uma lista de itens a partir de uma view com o nome ListName, paginada e com os filtros definidos por Filter. Fica bastante simples para o volume de dados gerado!

Claro que existem muitos outros detalhes referentes à orquestração e manipulação de dados, integração com a parte de segurança, validação etc. Mas acho que deu pra se ter uma idéia de onde se pode chegar com uma estrutura destas. Tem toda a parte de suporte de componentes de cliente, que são implementandos com bibliotecas comuns como jQuery e controles javascript. O jQuery em específico é uma grande ferramenta de produtividade para a manipulação de conteúdo HTML, porém sempre em códigos pequenos, para complementar alguma necessidade de tela que não faz sentido ser contemplada pelo framework.

Com o uso do framework, eu tenho visto os índices de produtividade estão se elevando cada vez mais. Com o framework, incluir uma nova entidade com a criação da tabela, definição da entidade de domínio, criação da tela de lista e de edição para CRUD, é uma tarefa que não leva mais do que alguns minutos. Isto é comparável aos geradores das melhores linguagens dinâmicas atuais, mantendo a tipagem do C#. Claro que um sistema tem somente pequena parte do esforço gasto em CRUD, mas com estes recursos é possível definir e construir telas que são simples de dar manutenção, de maneira extremamente rápida. O nosso processo atual é pedir pro designer gráfico gerar o HTML; a gente quebrar o HTML em layout e DSL e depois fazer os controllers.  Claro que isto tudo só vale se o investimento na construção de todos estes componentes for amortizado em muitos sistemas em produtos.

Isto conclui a descrição dos componentes do framework. No próximo post, a conclusão desta série, com a minha visão de como a produtividade é afetada por todos estes artefatos. Até mais.