Embora eu nunca tenha entregado nada usando o Smalltalk, meu breve tempo brincando com ele definitivamente deixou sua marca. A única maneira de descrever a experiência é o MVC do jeito que deveria ser. Essencialmente, todo o trabalho pesado para seu aplicativo é feito nos objetos de negócios (ou no modelo de domínio, se você preferir). Os controles padrão são vinculados aos objetos de negócios de alguma maneira. Por exemplo, uma caixa de texto é mapeada para o campo de um objeto (o próprio campo é um objeto, por isso é fácil de fazer). Um botão seria mapeado para um método. Tudo isso é feito com uma API muito simples e natural. Não precisamos pensar em vincular objetos etc. Isso simplesmente funciona.
No entanto, em muitas linguagens e APIs mais recentes, você é forçado a pensar de fora para dentro. Primeiro com C ++ e MFC, e agora com C # e WPF, a Microsoft colocou seu mundo de desenvolvedores conectado aos construtores de GUI nos quais você constrói seu aplicativo implementando manipuladores de eventos . O desenvolvimento do Java Swing não é tão diferente, apenas você está escrevendo o código para instanciar os controles no formulário. Para alguns projetos, talvez nunca haja um modelo de domínio - apenas manipuladores de eventos. Estive dentro e fora deste modelo durante a maior parte da minha carreira.
Cada maneira força você a pensar de maneira diferente. Com a abordagem Smalltalk, seu domínio é inteligente enquanto sua GUI é burra. Com a abordagem padrão do VisualStudio, sua GUI é inteligente, enquanto o modelo de domínio (se existir) é bastante anêmico.
Muitos desenvolvedores com quem trabalho valorizam a abordagem Smalltalk e tentam aplicar essa abordagem no ambiente do VisualStudio. O WPF possui alguns recursos de ligação dinâmica que possibilitam; mas existem limitações. Inevitavelmente, algum código que pertence ao modelo de domínio acaba nas classes da GUI.
Então, de que maneira você cria / desenvolve seu código? Por quê?
- GUI primeiro. A interação do usuário é fundamental.
- Domínio primeiro. Preciso garantir que o sistema esteja correto antes de colocarmos uma interface do usuário.
Há prós e contras para qualquer abordagem. O modelo de domínio se encaixa com catedrais de cristal e torta no céu. GUI se encaixa lá com rápido e sujo (às vezes muito sujo).
E para um bônus adicional: como você garante que o código seja sustentável?