Posts Marcados MVC

Novidades!

Olá pessoal, há quanto tempo!! :)…. Estive ontem no Visual Studio Summit 2015 e continuo achando este o melhor evento da Microsoft para desenvolvedores. Este ano esteve especialmente bom já que temos muitas tecnologias e plataformas a caminho, tais como o Visual Studio 2015, o ASP.NET 5 e o C# 6.0. Foi bom poder conversar como os early-adopters e colher opiniões sobre o que temos de bom em cada novidade destas. Sem entrar muito em detalhes, é suficiente dizer que fiquei positivamente impressionado, fazia tempo que não via a Microsoft engajada em disponibilizar tantos recursos para os desenvolvedores. E é perceptível também o esforço em começar a integrar os produtos Microsoft com as outras plataformas, como o Visual Studio Code para Mac e Linux e nos novos recursos de integração do Visual Studio 2015 RC com o melhor do mundo open source, tais como Node.js NPM, Grunt e Bower. Para quem ainda não baixou o Visual Studio 2015 RC, recomendo fazer isto logo, vale a pena no mínimo para se preparar para estas mudanças.

Na White Fox, continuamos firmes na nossa transição de desenvolvimento MVC clássico para um modelo baseado em MVC REST APIs e uma interface rica baseada em AngularJS. Praticamente todos os nossos sistemas já possuem telas desenvolvidas com esta tecnologia e novos sistemas estão sendo feitos exclusivamente neste formato. É cada vez mais comum também expormos estas APIs para interfaces desenvolvidas para dispositivos móveis, o que faz com que nossas APIs tenham que ser desenvolvidas com um agnosticismo completo com relação às interfaces que a vão utilizar. Se por um lado isto é uma boa prática, por outro significa migrar centenas de telas de legado para este novo formato, o que muitas vezes é bem custoso.

Na parte de ORM, continuamos sem um norte claro. A maior parte de nossos sistemas continua usando a versão antiga do nHibernate com o Castle ActiveRecord. Porém a idade está começando a pesar nesta plataforma, começando a tornar difícil algumas evoluções que precisamos fazer. Fizemos algumas tentativas de migração para o Entity Framework com relativo sucesso usando o Entity Framework 6. Porém, como nossos sistemas são muito complexos (centenas de entidades), o esforço de mapeamento é considerável, e temos bugs sérios no designer do EF6 com relação a defaults de banco de dados, o que torna a atividade ainda mais complicada. E, para detonar de vez este cenário, o EF7 vai remover o modelo “database-first”, o que inviabiliza o que fizemos até agora.

Esta questão do EF7 me intriga. Conversando ontem com outros desenvolvedores, percebi que muitos têm problemas similares. O uso do EF com sucesso acontece quando o sistema é novo e tem um único “dono” para banco de dados. Porém isto não é comum na nossa realidade (e, pelo que vi, de muitas outras), pois o banco é compartilhado entre vários sistemas legados e não há um único responsável pela evolução do mesmo. Neste aspecto, até a proposta da Microsoft para substituir o modelo database-first pelo code-first com migrations não resolve, pois temos alterações que não viriam do EF. Parece que não teremos alternativa a não ser codificar os objetos na mão (e voltamos 10 anos no tempo!!). Pelo menos o uso do Power Tools para o EF deve ajudar um pouco. E estamos de olho em ferramentas de terceiros, como as da DEVART, que também podem ser uma alternativa. Mantenho vocês informados da nossa evolução.

Outro tópico muito interessante ontem foi o relativa à Microservices. Percebi que outras pessoas estão com o mesmo problema que o nosso, que é manter a agilidade em sistemas de grande porte, onde o processo de deploy é amarrado por inúmeros problemas: demoras em homologação, sistema monolítico etc. Microservices podem ser uma solução para isto, a ideia é decompor o sistema em componentes de serviço e com isto podermos substituir um ou outro sem afetar a aplicação como um todo. Em teoria, a ideia é boa, mas, na prática, ainda não temos uma plataforma definida para implementarmos isto. As implementações de Microservices normalmente fazem uso de filas de mensagens, o que gera problemas para sistemas que exigem uma resposta síncrona. Além disto ainda temos que escolher uma boa plataforma para implementar este barramento de serviços/mensageria. O Microsoft Azure tem uma implementação interessante, porém ele não é uma opção para sistemas internos. Estamos analisando possibilidades como o Service Broker do próprio SQL Server ou soluções open source como o RabbitMQ, vamos ver como fica isto nos próximos meses.

Até a próxima!

, , , ,

2 Comentários

De volta 2!

Oi pessoal!! Depois de um looooongo tempo sem postar, finalmente consegui um tempinho. Olhando o último post, dá pra notar que estávamos extremamente ocupados no início do ano passado. Mal podíamos imaginar o que viria pela frente. Do ano passado para cá, iniciamos um enorme projeto com um de nossos clientes, o Sistema de Ensino Poliedro, que nos tomou praticamente 1 ano de contínua dedicação e deve ainda prosseguir por bastante tempo.

O projeto foi participar da construção de aplicativos móveis, iOS (iPhone e iPad) e Android (smartphones e tablets), para disponibilizar para alunos uma grande parte das informações até então só existentes no site, como agenda, notas, resultados de simulados etc. Nossa parte foi expor em serviços toda a infraestrutura do domínio que tínhamos em sistemas, de forma a funcionar tanto para os aplicativos móveis quanto para uma nova versão web, também a ser desenvolvida. Trabalhamos com empresas parceiras, que ficaram responsáveis pela construção das interfaces móveis e web.

O maior desafio foi a definição desta API de serviços, para ser o mais reusável possível sem comprometer a facilidade e uso pelas interfaces. E tinha que ser extremamente escalável, já que o número de alunos previstos para os aplicativos era superior a 30.000.

A nossa opção foi utilizar a ASP NET MVC Web API. Uma das grandes vantagens desta arquitetura foi que o Web API já é capaz de retornar dados em vários formatos, como XML e JSon, o que foi providencial para nossa meta de reusabilidade. E por ser bem leve, atendeu bem também a necessidade de escalabilidade.

Como o sistema é, em quase todas as telas, somente leitura, optamos por otimizar o acesso a dados com a criação de banco de dados construídos especialmente para este fim. Assim, desenvolvemos procedimentos para trazer dados dos nossos bancos transacionais e produzir uma informação desnormalizada, pronta para consumo pela interfaces. Embora isto tenha exigido uma grande capacidade de processamento para gerar esta informação consolidada (optamos por executar isto durante as madrugadas), o acesso de cada uma das interfaces ficou extremamente rápido e escalável.

O resultado foi um sucesso completo. Os aplicativos iOS e Android tiveram centenas de downloads nos primeiros dias e hoje, menos de 6 meses após o lançamento, já temos mais de 10.000 aparelhos, entre tablets e smartphones, com acessos de alunos. O resultado foi tão positivo que já continuamos no mesmo ritmo para construção de mais aplicativos, agora voltados para professores e gestores. Nosso cliente provavelmente é hoje uma das instituições mais modernas do país, em termos de software. Ficamos super orgulhosos de termos participado deste projeto!

Em paralelo a isto, outros clientes nossos estão nos demandando bastante. Com isto, a White Fox está totalmente ocupada e estamos em busca urgente por bons desenvolvedores. Se você quer saber mais ou se candidatar, envie-nos seu currículo para rh@whitefox.com.br

Espero não demorar mais um ano para o próximo post! Até breve!

P.S.: Para quem ainda não se inscreveu e está no rio, não percam o DNAD 2013, nestes dias 2 e 3 de agosto. A grade de palestras está excelente e a White Fox é uma das patrocinadoras!

, , , , , , , , ,

Deixe um comentário

Engine MVC baseada em XSLT

Na série sobre produtividade, no post sobre a camada de interface, eu  falei um pouco sobre o uso de XSLT na transformação de arquivos XML para gerar HTML. Várias pessoas me pediram mais detalhes sobre a engine utilizada. Neste artigo, vou entrar em mais detalhes desta engine usando o MS-MVC e fazer um paralelo com a implementação Monorail. Este artigo é bem técnico e pressupõe que o MS-MVC seja bem conhecido, em especial na parte de criação de custom view engines.

No download do MS-MVC existe uma View Engine baseada em XSLT. Existem também outras iniciativas como a Chris Hampson. Estas não nos atenderam porque se baseiam em um arquivo XML que é transformado diretamente pelo XSLT. No nosso caso é necessário injetar, além do arquivo XML de definição, dados que serão utilizados também pelo XSLT pra construir a tela. Finalmente, as atividades realizadas pelo controller também interferem na página resultante. Por exemplo, se uma ação gera um erro, a página resultante deve ser um redirecionamento para a página de tratamento de erros. Estas razões fizeram com que a gente desenvolvesse a nossa própria ViewEngine.

Em linhas gerais, a nossa ViewEngine simplesmente obtém o XML de definição, o XML de dados (que chamamos de DataIsland) e aplica um XSLT para gerar um HTML resultante (ver o post sobre camada de interface para exemplos destes artefatos). Para fazer isto no MS-MVC, é necessário implementar duas classes: uma que implemente a interface IViewEngine e uma que implemente a IView. Além destas duas, a implementação de nossa engine usa um controller base, para que possamos interceptar alguns métodos (ver adiante).

A IViewEngine tem que implementar os métodos FindView, ReleaseView e o FindPartialView. No nosso caso, a única coisa importante é o FindView. Este método é responsável por identificar o arquivo de definição XML e passar o tipo de ação e dados de apoio para a ViewBase, conforme código a seguir:

private ViewEngineResult FindView(ControllerContext controllerContext) {
            
            var server = controllerContext.HttpContext.Server;
            const string extension = "html";
            var area = string.Empty;

            if (controllerContext.RouteData.Values.ContainsKey("area")) 
                area = controllerContext.RouteData.Values["area"] + "/";

            var controller = (BaseController)controllerContext.Controller;
            var controllerName = 
                controller.GetType().Name.Replace("Controller", "")
                   .ToLowerInvariant();
            var path = string.Empty;
            if (controller.OutputType == OutputType.Html || 
                controller.OutputType == OutputType.XmlView) {
                if (controller.ViewNameOrigin == 
                        BaseController.ViewNameOriginType.Controller 
                    && string.IsNullOrEmpty(controller.ViewName))
                    path += string.Format("~/views/{0}{1}.{2}", area, 
                            controllerName, extension);
                else
                    path += string.Format("~/views/{0}{1}/{2}.{3}", area, 
                        controllerName, controller.ViewName ?? 
                        controller.ActionName, extension);
                if (!File.Exists(server.MapPath(path)))
                    return new ViewEngineResult(new[] { path });
                path = server.MapPath(path);
            }

            var dataIsland = 
                  (controller.OutputType != OutputType.XmlAction) ? 
                                controller.GetDataIsland() : null;
            var view = new XsltView(controller.OutputType, 
                controllerContext.RouteData.Values["area"].ToString(), 
                path, controllerName, controller.ActionName,  
                dataIsland == null ? null : dataIsland.Root, 
                controller.ElementsToRender, controller.Message, 
                controller.RedirectUrl);          
            return new ViewEngineResult(view, this);
        }

 

Como pode ser visto acima, temos dois casos de arquivos de definição. Alguns que tem o próprio nome do controller, e alguns que tem o nome da action, situados em um folder com o nome do controller. A última parte deste método chama o construtor da XsltView, que implementa a IView.

A XsltView é que contém o código principal da ViwEngine. Ela é responsável por efetivamente fazer a transformação XSLT e depois fazer escrever o HTML gerado. A transformação no nosso caso é um pouco mais complexa do que simplesmente rodar o Transform() de uma classe XsltCompiledTransform do C#. A gente faz também uma série de manipulações no XML de origem, fazendo a junção dele com o XML do DataIsland, alterando paths relativos (por exemplo, substituindo string ‘~/’ pelo path físico da aplicação) e suportando áreas que possuem XSLTs diferentes (por exemplo, temos áreas que simplesmente injetam HTML final; temos outras que usam pequenos templates XSLTs para cada controle; e outras que simplesmente fazem referência a um XSLT externo). Esta transformação poderia ser tema de um artigo por si só, quem tiver interesse em saber mais sobre ela, envie-me um email direto.

O método Render da XsltView é mostrado a seguir. Como mencionei acima, dependendo da ação executda nós podemos ter vários resultados possíveis. Temos HTML simples e, para chamadas que foram feitas por AJAX, temos opção de mandar mensagens de alerta, trechos de HTML para serem substituídos ou simples comandos de Redirect. Para suportar isto, fizemos uma mensagem XML que é decodificada por um arquivo .js que é responsável por tomar a decisão correta do que fazer com base nos elementos enviados.

public void Render(ViewContext viewContext, TextWriter writer) {
  XElement result;
  if (outputType == OutputType.Html) {
      var ns = GetNamespaces(contents.Document);
      if (!String.IsNullOrEmpty(redirectUrl)) {
       writer.Write("<html><script language='javascript'>location.href='" 
           + redirectUrl + "';</script></html>");
       return;
      }
      else {
       result = contents.XPathSelectElement(HtmlElementPath, ns);
       writer.Write(@"<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML 1.0 
 Transitional//EN' 'http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd'>");
      }
  }
  else {
      viewContext.HttpContext.Response.ContentType = "text/xml";
      result = new XElement("Result");                
      if (!string.IsNullOrEmpty(message))
        result.Add(new XElement("Message", message));       
        if (!String.IsNullOrEmpty(redirectUrl)) {
           result.Add(new XAttribute("status", 
                       hasView ? "redirect" : "ok"));
           result.Add(new XElement("Redirect", redirectUrl));
        }
        else {                    
           switch (outputType) {
             case OutputType.XmlAction:
                result.Add(new XAttribute("status",  "ok"));
                break;
             case OutputType.XmlMessage:
                result.Add(new XAttribute("status",  "message"));
                break;
             case OutputType.XmlDataOnly:
                result.Add(new XAttribute("status", "ok"));
                result.Add(contents);
                break;
             case OutputType.XmlView:
                result.Add(new XAttribute("status", "ok"));
                if (elementsToRender != null) {
                   foreach (var element in elementsToRender) {
                      var ns = GetNamespaces(contents.Document);
                      var idName = element;
                      if (element == "Form" || element == "List"
                            || element == "CRUDList") {
                         idName = element + "Contents";
                         result.Add(
                           new XAttribute("configurePage", "true"));
                      }
                      var dataContents =
                      contents.XPathSelectElement(
                      String.Format("//*[name()='div' and @id='{0}']",
                             idName), ns);
                      if (dataContents == null) continue;
                      var item = new XElement("Data");
                      item.Add(new XElement("Id", idName));
                      var html = new XElement("Contents");
                      html.Add(new XCData(dataContents.ToString()));
                      item.Add(html);
                      result.Add(item);
                   }
                }
                break;
          }
     }
   }
   writer.Write(result.ToString());
}

O último componente da engine é o BaseController. Este controller faz o override de dois métodos do MS-MVC, o primeiro é o OnActionExecuting e OnActionExecuted, mostrados a seguir.

protected override void OnActionExecuting(
                                     ActionExecutingContext context) {
    ActionName = 
             context.ActionDescriptor.ActionName.ToLowerInvariant();
    if (HasAttribute<XmlResultAttribute>(context.ActionDescriptor)) {
        OutputType = OutputType.XmlView;
        var viewName = GetViewName(context.ActionDescriptor);
        if (!string.IsNullOrEmpty(viewName)) ViewName = viewName;
    }
    else 
        if (HasAttribute<ActionResultAttribute>(
                                   context.ActionDescriptor)) {
            OutputType = OutputType.XmlAction;
        }
        else
            if (HasAttribute<DataOnlyResultAttribute>(
                                    context.ActionDescriptor))
                OutputType = OutputType.XmlDataOnly;
            else {
                if (HasAttribute <HtmlResultAttribute>(
                                       context.ActionDescriptor)) {
                    var viewName =
                             GetViewName(context.ActionDescriptor);
                    if (!string.IsNullOrEmpty(viewName)) 
                              ViewName = viewName;
                }
                OutputType = OutputType.Html;
            }
    base.OnActionExecuting(context);
}

protected override void OnActionExecuted(ActionExecutedContext context) {
    if (context.Exception != null && !context.ExceptionHandled) {
        if (OutputType != OutputType.Html) {
            ProcessException(context.Exception);
            context.ExceptionHandled = true;
        }
    }
    base.OnActionExecuted(context);
}

Como pode ser visto, antes da execução, através de atributos da action, é possível determinar qual o tipo de retorno desejado. E após a execução, caso tenha ocorrido alguma exceção, é feito um tratamento da mesma.

Acho que deu para ter uma idéia de como a nossa engine foi construída. No Monorail, tudo funciona exatamente da mesma forma, a única diferença são nomes diferentes para interfaces e métodos do controller. No Monorail ao invés da IViewEngine, temos que herdar da ViewEngineBase. Não há interface específica para a View pois quem faz o Render é a própria ViewEngineBase. E no controller, o método a sofrer override é o InvokeMethod. Se alguém desejar informações específicas sobre o Monorail ou sobre qualquer outra área desta engine, basta me mandar um email.

, , , , , ,

Deixe um comentário

Produtividade – Camada de Interface Parte 2

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.

, , , ,

Deixe um comentário

Produtividade – Camada de Interface Parte 1

Em mais um post sobre a série sobre produtividade, vou escrever sobre a camada de interface. Por interface eu me refiro à web, já que é raro nós termos grandes desenvolvimentos de aplicativos Windows – e mesmo nestes casos não é algo problemático, o desenvolvimento em Windows Forms do .NET é bastante tranqüilo para aplicações de pequeno porte. Intrefaces baseadas em serviços também são super simples para serem construídas, ainda mais usando a WCF Factory. Assim, o foco é a construção de páginas web. Para não tornar este post muito longo, eu o dividi em duas partes.

Na minha experiência, o desenvolvimento de interfaces web é onde se gasta mais de 90% do tempo de desenvolvimento e manutenção de qualquer sistema de médio ou grande porte. É também onde a evolução tecnológica se faz mais sentir, a disseminação de uso do AJAX, por exemplo, mudou completamente o modo como se desenvolve para web. E para os usuários, a qualidade da interface e navegabilidade muitas vezes é um dos maiores fatores de sucesso ou fracasso de um sistema, fazendo com que o investimento nestes artefatos seja primordial.

Para ilustrar o que busco, vou começar descrevendo o que pra mim é o pior cenário possível para interfaces. Tenho certeza que quem desenvolve para web já viu algo assim em algum momento da carreira. Todo sistema começa bem e o ASP.NET WebForms ainda é o método mais comum de construção utilizado. Assim, no início da vida do sistema, as telas são feitas de maneira mais ou menos rápida. Porém com o tempo, os usuários pedem evoluções para suportar algo pouco usual, um ou outro desenvolvedor menos experiente acaba colocando sua “contribuição” para as telas e o que antes era simples se torna extremamente complexo. Depois de alguns anos (ou meses, dependendo do sistema), o que temos é uma coleção de aberrações, cada tela com código específico, com coisas indo pra sessão outras para viewstate, código inline (com o famigerado <% %>), regras de negócio em .cs de páginas (ou ainda, pesadelo dos pesadelos, no mais famigerado <% %>). Se o sistema foi portado do ASP então, a visão dantesca se completa, pois nestes caos é difícil encontrar qualquer coisa minimamente estruturada. O uso de componentes de terceiros ou frameworks só complica, pois também tendem a gerar ainda mais telas fora do padrão, com todos os tipos de “puxadinhos” imagináveis. Ou seja, em casos como este é muito mais fácil refazer a aplicação do que tentar arrumar. Porém quando se resolve reconstruir, o ciclo se repete e daqui a alguns anos (ou meses!) está tudo como era – normalmente deixando mais um legado para se manter, para a infelicidade de quem ficou.

Como resolver isto? Como desenvolver rapidamente e ainda assim gerar sistemas que não se autodestruam com a manutenção/evolução? A solução que eu uso são frameworks de interface que tentam garantir a estruturação das interfaces de uma maneira que facilite que os desenvolvedores fiquem em um padrão pré-estabelecido e ao mesmo tempo tentando gerar o máximo de flexibilidade possível. Nesta linha, eu tenho sistemas desenvolvidos há quase oito anos que continuam bem estruturados. Naquela época a amarração era tão forte que as telas produzidas eram muito simples, gerando sistemas de usabilidade ruim, comparando com os atuais. Porém existem vários operando até hoje que são simples de manter e (até hoje) de evoluir. De lá pra cá a evolução do framework já permite gerar telas extremamente amigáveis, mantendo ainda os níveis de manutenabilidade originais. Claro que esta não é uma solução para qualquer empresa ou time, o nível de treinamento e envolvimento com o framework é muito alto para ser facilmente replicável. Mas no nosso caso está sendo muito bem sucedido.

O framework utiliza um tipo de padrão MVC, porém com uma separação clara em 4 componentes: 1) Estruturas de Interface – aqui entram caixas de texto, checkbox, botões, listas etc. São itens que contém os dados sendo apresentados e que serão manipulados pelos usuários. 2) Layout – que é como as estruturas de interface são mostradas em tela. No layout entra toda a parte visual como estilos, manipulação visual (via jQuery por exemplo), controles, figuras e até coisas como uso de janelas popup ou chamadas AJAX. 3) Dados – utilizando um conceito que também utilizado no Microsoft Sharepoint, definido em uma ilha de dados XML que contém todas as informações que serão utilizados pela interface. 4) Controllers – controladores da interface, onde os dados são construídos e as ações executadas, fazendo uso das entidades de domínio e chamando os serviços da mesma.

Separando desta forma, fica fácil notar quais elementos são afetados quando há uma mudança, fazendo com que a mesma impacte o menos possível os demais. Esta estruturação faz com que o desenvolvimento de novas telas seja concentrado em 2 pontos, na definição de estrutura de interface e nos controllers. A clara separação existente evita que uma área afete outra.

Na minha experiência, o Layout é um dos pontos que mais evoluem na interface. Embora em linha gerais ele fique estático (p. ex., pode se definir que o sistema vai ter um cabeçalho com o nome do sistema, usuário logado e menu; no meio com uma área de formulários e listas e com inclusões em popup, tudo usando Ajax), as pequenas modificações acabam sendo freqüentes. É a inclusão de um novo elemento no cabeçalho, o suporte de uma lista hierárquica, um novo tipo de componente e assim por diante. Para garantir que não aja uma mistura de responsabilidades, eu uso XSLT para a definição de todos os artefatos de layout. Este é um dos pontos de maior dificuldade de aprendizado no framework, já que não é usual que desenvolvedores usem diariamente XSLT. Mas, como falei no post sobre princípios, o XSLT é uma linguagem declarativa que evita o uso de código imperativo e o uso de artefatos como sessão, viewstate etc. E uma vez dominado, o XSLT é extremamente eficiente para se gerar o HTML final (sem falar que já gera o HTML correto!).

Para gerar o HTML final, os arquivos XSLT de layout utilizam duas fontes de transformação: os dados e a estrutura de interface. Isto já faz com que os dados tenham que ser facilmente descritos em XML. Eu vou a um ponto mais extremo, fazendo com que todos os nossos dados sejam descritos somente em XML – também como é feito no Microsoft Sharepoint. Com isto, minimizamos o uso de objetos DTO e tornamos a estrutura de dados da interface completamente maleável e fácil de evoluir.

Finalmente, a estrutura de interface também deve ser descrita em XML, para que seja facilmente transformável. O que fizemos foi criar uma DSL, integrada ao Visual Studio (com intellisense, claro), para descrever cada elemento de interface. Vejam como fica um exemplo simples de um formulário de login:

Exemplo de DSL de Interface:

<Form defaultFocus="Login">
     <Field data="Login" type="textbox" required="true" label="Login"  />
     <Field data="Senha" type="textbox" required="true" label="Senha"  password="true" />
     <Command label=”Logar” action=”Login”/>
</Form>

Exemplo de XSLT de Layout (super reduzido para efeito de ilustração):

<xsl:stylesheet version="1.0" >
     <xsl:template match="Form">
          <html>
                <body>
                     <form method="post">
                          <xsl:apply-templates select=”Field|Command” mode=”Control”/>
                     </form>
                 </body>
           </html>
      </xsl:template>
</xsl:stylesheet>

No XSLT acima, cada Field é transformado em um input box e o Command em um button. Percebam que não há código inline – não existe o <% %>. Este tipo de arquitetura era muito dificil de ser construída e mantida no ASP.NET Webforms, o que tornava o framework bastante complexo. Felizmente com o advento de bibliotecas MVC, isto ficou muito mais simples. Inicialmente, criamos  uma View Engine para suportar esta DSL no Castle Monorail. Com o advento posterior do ASP.NET MVC, criamos uma a View Engine para ele que funciona com exatamente a mesma DSL e os mesmos arquivos de layout. Esta migração mostrou a capacidade de evolução do framework, o que me deixa tranquilo para encarar a manutenção dos nossos sistemas por, quem sabe, outros 8 anos por vir.

No próximo post vou explicar como as ações são executadas e entrar nos detalhes dos controllers, mostrando como isto tudo se integra.

Até breve!

, , , , , , , , ,

1 comentário