JavaFX - a maneira correta de usar Propriedades com objetos de domínio

10

O JavaFX forneceu vários novos objetos Property, como os javafx.beans.property.DoublePropertyque permitem definir campos que podem ser observados e sincronizados automaticamente.

Em muitos exemplos de JFX, a classe de modelo MVC possui vários desses campos de Propriedade, que podem ser vinculados automaticamente à visualização.

No entanto, isso parece estar nos encorajando a colocar propriedades JFX em nossos objetos Domain (se você assumir que a classe Model será um objeto de domínio), o que me parece uma fraca separação de preocupações (por exemplo, colocar código GUI no domínio )

Alguém viu esse problema sendo resolvido na "vida real" e, se sim, como foi feito?

properties javafx domain-objects

— pjm56
fonte

Corrija-me se estiver errado, mas meu entendimento do JavaFX foi que ele foi arquivado pela Sun em 2008 antes da compra da Oracle e só foi reformado no mercado com a descontinuação do Silverlight e do Declínio do Flash em dispositivos Apple. Talvez você esteja certo de que está bem acoplado à vista e de uma razão original pela qual foi colocada em espera ao sol. Apenas um pensamento.

— 7602 Jack Stone

A Sun e agora a Oracle trabalham continuamente no JavaFX há vários anos. A principal mudança recente foi interromper a linguagem de programação "JavaFX Script" necessária para usar o JavaFX e mudar para o Java comum. Essa mudança foi motivada pela baixa adoção e despesa de suporte a uma linguagem de programação totalmente nova.

— Stuart Marks

4

Venho brincando com o JavaFX 2.0, sobre o qual suponho que sua pergunta seja. Não é um código de produção real, apenas um projeto pessoal, mas encontrei o mesmo problema que você mencionou acima. O modelo inteiro tende a se tornar dependente da estrutura 2D, e eu não gosto disso.

O que fiz, dividi todas as classes do modelo em duas, a classe real do modelo, que tem capacidade para carregar seu conteúdo do banco de dados, sabe como ele altera seu estado, etc etc ... e a classe de representação que decide a aparência na tela. Este último conteria todas as classes Property.

Você encontrará o mesmo design em qualquer estrutura MVC, como o Swing. é que aqui não há como escapar.

— Hannes R.
fonte

Uma estrutura que o força a aplicar bons princípios de design ou explode em seu rosto, se não o fizer. Como um cara do .NET, isso é muito familiar para mim.

— 23412 MattDavey

0

Quase 7 anos depois, e essa pergunta ainda é tão válida quanto antes.

Na minha opinião, o javafx nunca deve ser importado por nenhuma das classes pertencentes ao modelo. No entanto, eles podem funcionar muito bem se você adotar um MVVM combinado com a arquitetura MVC. Nesse sentido, o

entidades = modelo (domínio) ( M )
Arquivos FXML = visualização ( V )
o controlador ainda é o controlador ( C )
o modelo de visualização ( VM ) = um novo conjunto de classes de dados que contêm apenas propriedades javafx e uma referência ao objeto de domínio real (M) que ele representa. Ele pode passar as chamadas do método de lógica de negócios para esse objeto, atuando como um composto / decorador.

Outra maneira de ver as coisas é pensar na classe do controlador como parte da visão, já que tudo o que faz é vincular o modelo de visão à visão (dados e ações). Portanto, poderia ser facilmente chamado de apresentador ou até fichário. Isso depende, no entanto, de como você usa o controlador. Se você adicionar lógica para manipular o modelo de exibição na classe Controller, ele merece seu nome e você terá a arquitetura apresentada acima. Se a classe do controlador vincular apenas os dados do modelo aos elementos da UI e o ActionEvents aos métodos de modelagem, você tenderá a apresentar a arquitetura mutante do MVVM abaixo.

Eu acho que essas arquiteturas de alguma forma combinam as idéias do tio Bob sobre arquitetura limpa (a camada de apresentação).

— Vlad Călin Buzea
fonte