Uml?

[quote=AlexandreGama][quote]
Por que perigoso?
Quando tenho que fazer um sistema (modulo), de acordo com o que o cliente deseja (Caso de uso), a primeira coisa que faço é extrair as tabelas e relacionamentos necessarios para que aquele sistema funcione. Apartir desse modelo pronto que eu passo para as classes
[/quote]

É perigoso pq você não sabe exatamente o que precisará e não sabe como será o seu design. O design do seu código te dirá exatamente o que fazer e onde armazenar. Se vc desenvolver com TDD por exemplo, as suas tabelas serão criadas a medida que cada funcionalidade sua nascer, ou seja, você mantem as coisas simples e só desenvolve aquilo que realmente precisa. Se você trabalhar com iterações por exemplo, com integras contínuas e com integração contínua, verá que o seu esforço tem q ser concentrado naquilo que precisa entregar, o que foge do modo orientado a banco de ser.

É regra para o mundo? não! Funciona? Muito bem!

Abs![/quote]

Como vc lida com a performance do banco de dados no CRUD?

[quote=AlexandreGama][quote]
Luiz Augusto Prado

Concerteza antes de passar para um ferramenta case, o papel e lápis “comem solto”, porém, após o esboço, creio que seria meio ruim você passar para um banco, por exemplo, todas as tuas ideias de relacionamentos, tanto é que tu teria que ficar umas boas horas amarrando as tabelas na mão…
[/quote]

Na verdade o seu banco deveria seguir a modelagem do seu sistema, e não o contrário. Programar orientado a banco de dados é perigoso não? :wink:

Abs![/quote]

“Programar orientado a banco de dados é perigoso não?”

Não! Com uma boa modelagem do banco de dados partindo dos requisitos do usuário, não vejo problema algum em modelar o banco e depois partir pro software, além do mais, fazer um sistema e depois o banco, ao meu ver, lhe dará imensos transtornos e remodelagem de banco…

Não entendi a pergunta

Partindo dos requisitos do usuário temos casos de uso, partindo dos casos de uso temas regras de negócio, partindo das regras de negócio temos o design do seu projeto. Se ele vai precisar ou não de um banco de dados, é aqui que vamos descobrir, se vamos
precisar guardar ou não o rg do cara, é aqui que vamos descobrir :wink:

O que quero dizer é que o desenvolvimento orientado a banco de dados te faz modelar algo que você não tem, algo que você imagina que existirá, o que muitas vezes pode não ocorrer. É uma questão de prioridade. Você prefere modelar algo que na hora você precisa, ou imaginar o que vc vai precisar, pra começar a modelar? :wink:

Abs!

[quote=AlexandreGama][quote]
Não! Com uma boa modelagem do banco de dados partindo dos requisitos do usuário, não vejo problema algum em modelar o banco e depois partir pro software, além do mais, fazer um sistema e depois o banco, ao meu ver, lhe dará imensos transtornos e remodelagem de banco…
[/quote]

Partindo dos requisitos do usuário temos casos de uso, partindo dos casos de uso temas regras de negócio, partindo das regras de negócio temos o design do seu projeto. Se ele vai precisar ou não de um banco de dados, é aqui que vamos descobrir, se vamos
precisar guardar ou não o rg do cara, é aqui que vamos descobrir :wink:

O que quero dizer é que o desenvolvimento orientado a banco de dados te faz modelar algo que você não tem, algo que você imagina que existirá, o que muitas vezes pode não ocorrer. É uma questão de prioridade. Você prefere modelar algo que na hora você precisa, ou imaginar o que vc vai precisar, pra começar a modelar? :wink:

Abs!

[/quote]

Por isso que gosto do papel e do lápiz.
É no momento que estou criando meu diagrama de classes que vou modelando o banco de dados.
Como o colega acima falou, começar pelo banco de dados evita problemas futuros.
Mesmo depois de o sistema estar pronto ele pode evoluir e ser atualizado. Isso pode lhe exigir uma manutenção ou migração em tabelas ou dados muito caóticos se seu banco de dados fosse baseado em uma view, por exemplo.

A qualquer momento vc pode ver que mudando, removendo ou acrescentando uma tabela (com relacionamentos) isso vai afetar aperformance do seu sistema ou do seu desenvolvimento.
Seja no tempo para que seu banco de dados apresente os resultados, na qualidade do sistema, tempo de desenvolvimento ou seja na usuabilidade.

Você cria diagramas de classe antes de iniciar um projeto? A partir do diagrama de classes vc cria o seu banco? 0_o

Banco de dados baseado em uma view? 0_o

[quote=AlexandreGama][quote]
Por isso que gosto do papel e do lápiz.
É no momento que estou criando meu diagrama de classes que vou modelando o banco de dados.
Como o colega acima falou, começar pelo banco de dados evita problemas futuros.
Mesmo depois de o sistema estar pronto ele pode evoluir e ser atualizado. Isso pode lhe exigir uma manutenção ou migração em tabelas ou dados muito caóticos se seu banco de dados fosse baseado em uma view, por exemplo.

A qualquer momento vc pode ver que mudando, removendo ou acrescentando uma tabela (com relacionamentos) isso vai afetar aperformance do seu sistema ou do seu desenvolvimento.
Seja no tempo para que seu banco de dados apresente os resultados, na qualidade do sistema, tempo de desenvolvimento ou seja na usuabilidade.
[/quote]

Você cria diagramas de classe antes de iniciar um projeto? A partir do diagrama de classes vc cria o seu banco? 0_o[/quote]

Sim, quanto recebo o pedido do sistema vejo tudo o que é necessario.
Apartir disso começo com papel e lápiz desenhando as classes prevendo as tabelas e relacionamentos no banco.
Então, com esse minimo, eu começo modelando o banco de dados.
Aqui tem um exemplo de como faço com anottations para eu gerar meu banco:


package testeorm.Interfaces;

import testeorm.DialectMySQL;
import orm.generators.Annotations.*;

@Table( DataBase="db_condominio", Nome="Usuario"  )
public interface Usuario
{
	@Column(SqlDataType=DialectMySQL.DataType_INT, Key=DialectMySQL.KeyType_PRIMARY, AutoIncrement=true, Nullable=true, lengthMax=11, lengthMin=1)
	public int idUsuario();

	@Column(SqlDataType=DialectMySQL.DataType_VARCHAR, Key=DialectMySQL.KeyType_UNIQUE, Nullable=false, lengthMax=16, lengthMin=8)
	public String login();

	@Column(SqlDataType=DialectMySQL.DataType_VARCHAR, Nullable=false, lengthMax=32, lengthMin=8)
	public String senha();

	@Column(SqlDataType=DialectMySQL.DataType_BOOLEAN, Nullable=false, lengthMax=3)
	public boolean ativo();

	@Column(SqlDataType=DialectMySQL.DataType_DATE, Nullable=false, lengthMax=8)
	public String dataEntrada();

	@Column(SqlDataType=DialectMySQL.DataType_DATE, Nullable=true, lengthMax=8)
	public String dataSaida();

	@Column(SqlDataType=DialectMySQL.DataType_INT, Key=DialectMySQL.KeyType_INDEX, Nullable=false, lengthMax=11, lengthMin=1)
	@Foreign(ForeignKeyOf=testeorm.Interfaces.Pessoa.class, ForeignKeyName="idPessoa")
	public int idPessoa();
}

Não tenho nada contra a sua metodologia, mas prever as tabelas, prever relacionamentos e sair desenvolvendo orientado ao banco acho no mínimo perigoso(again!). Se você define classes antes mesmo de codificar,
quer dizer que você não tem uma suite de testes certo? Ou no mínimo cria os seus testes depois da sua implementação correto? Viu o perigo? Modelar algo no banco que no existe, para um código que você ainda não tem,
e para um requisito que ainda não existe no seu design.

Por curiosidade, o que seria isso no seu código? Um ORM proprietario?

[quote=AlexandreGama][quote]
Sim, quanto recebo o pedido do sistema vejo tudo o que é necessario.
Apartir disso começo com papel e lápiz desenhando as classes prevendo as tabelas e relacionamentos no banco.
Então, com esse minimo, eu começo modelando o banco de dados.
Aqui tem um exemplo de como faço com anottations para eu gerar meu banco:
[/quote]

Não tenho nada contra a sua metodologia, mas prever as tabelas, prever relacionamentos e sair desenvolvendo orientado ao banco acho no mínimo perigoso(again!). Se você define classes antes mesmo de codificar,
quer dizer que você não tem uma suite de testes certo? Ou no mínimo cria os seus testes depois da sua implementação correto? Viu o perigo? Modelar algo no banco que no existe, para um código que você ainda não tem,
e para um requisito que ainda não existe no seu design.[/quote]

Se eu não tenho dados, por que preciso de designer?
Quando entendo o que o cliente quer, entendo que dados ele quer. Por isso não entendi porque fala que o banco não é um requisito do sistema?
Estamos falando de joguinho, ou módulo ou classe especifico que não necessite de um banco de dados?

Sim, testo cada metodo que vou acrescentando.
O teste é simular o máximo de combinação de casos que o tempo permitir parar cada metodo da classe.
De acordo com a codificação que escolher para o banco, vc poda um monte de decisoes das camadas acima. Exemplo: se colocar delete cascate=on num relacionamento não precisarei ficar verificando permissões no codigo. Assim, faço os testes levando em conta esses tipos de restriçoes em consideração.

[quote=AlexandreGama][quote]
SqlDataType=DialectMySQL.DataType_VARCHAR

@Table( DataBase=“db_condominio”, Nome=“Usuario” )
[/quote]

Por curiosidade, o que seria isso no seu código? Um ORM proprietario?[/quote]

Esse fonte é do link que passei.

To dando esse exemplo pra te mostrar que existem outros paradigmas.

Quem te diz como você codificará são os requisitos, as regras de negócio e não os dados.

Você testa cada método que vai acrescentando ou acrescenta um método pra cada teste? Há uma grande diferença aqui também

Será que estamos falando do mesmo tipo de teste?

De acordo com a codificação que escolher para o banco, vc poda um monte de decisoes das camadas acima. 

Não é mais facil, em vez de pensar o que será podado ou não, simplesmente podar na codificação, já que com um simples teste você terá um requisito testado e funcionando e limpo, sem precisar pensar em podar ou não.

Vejo o banco como infra e não como negócio. É um lugar burro que só envio e recebo coisas que quero guardar pra não perder.

Abs!

Mas este ORM é “caseiro”? Ele gera o seu banco a partir das suas classes? É isso?

Só para deixar claro, o seu paradigma é “programar orientado a banco de dados”? Vamos deixar claro para termos uma conversa sadia e eu nãoi falar A e vc entender B e vice versa =)

Abs!

Regras de negócio é o que o cliente quer executar. Se vc não entende o que o cliente quer, não tem como fazer o sistema.
Sim esse é um esboço de orm que estou fazendo.

Sim. Regras de negócios sao os problemas que o cliente quer resolver. Em nenhum momento banco de dados entra na conversa. Banco é infra :wink:

Pq? Para estudo ou para distribuição?

Abs!

Pessoas, não há o CERTO e o ERRADO nessa brincadeira de desenhar Sistemas.

Ambos modelos funcionam e é perfeitamente válido começar um Sistema a partir do modelo relacional.

O que o Alexandre está falando, é concentrado unicamente para Sistemas que querem apoiar-se na Orientação a Objetos para serem escaláveis, de fácil manutenção, livres de gambiarras, etc.

O que ele está tentando lhe mostrar é que começar a modelagem de um Sistema a partir de seu modelo relacional traz alguns perigos. Um dos pontos fortes na argumentação dele é que quando você modela um banco de dados relacional, você já está garantindo que seu sistema terá um Banco de Dados Relacional e que qualquer mudança desse paradigma pode ferrar com seu projeto lá na frente.

Esse exemplo não é meu, mas tenho uns amigos que começaram a modelagem de um Sistema há um tempo atrás e lá pelo 5º mês descobriram que o modelo reclacional ia ferrar com o que eles queria fazer. Tinham 2 opções;

1 - Inventar gambiarras relacionais que consertariam um problema e arranjariam outro;

2 - Pensar em uma alternativa ao modelo ER;

Depois de 1 ou 2 semanas de tentativas e algumas pogs, chegaram a conclusão que um banco Não Relacional seria a saída. Hoje o sistema está implementado no Voldemort;

Se você perceber, ficamos tão fechados nessa idéia de banco de dados relacionais que dificilmente conseguimos enxergar fora da caixa.

Outro perigo grande nessa abordagem é que Modelo OO !!!==== de Modelo ER.

Uma linha de uma tabela precisa de uma gambiarra de mapeamentos e Objetos Anêmicos para todos os lados pra poder ser representada em um Modelo OO.

Claro que para as argumentações acima você pode dizer que: “90% dos Sistemas hojes são resolvidos com modelos relacionais” e eu lhe respondo: “PERFEITO, você está certíssimo” e em nenhum momento posso contradizer tal afirmação.

Porém perceba que mesmo na afirmação acima temos algo que pode se tornar um grande problema. Seu usuário enxerga Software funcionando na cara dele e não banco de Dados. Com base nisso a preocupação do Alexandre é que se você monta seu banco de dados primeiro e fecha um Sistema em cima desse modelo, você corre o risco de 2 coisas:

1 - empacar algumas coisas na sua apresentação de dados por conta de tipos mal pensados;

2 - Quando as telas forem aparecendo e as manutenções também, o custo de mexer no BD aumenta consideravelmente, e o belo Modelo ER que foi pensado antes do designer da aplicação, começa a se comunicar com a mesma através da criação das malditas “FLAGS”, deixando o Sistema todo remendado e com regras confusas;

Com base nisso, respondo sua pergunta. Claro que é perfeitamente possível fazer um Sistema do 0, começando pelo modelo ER, em momento algum alguém discordou disso. O que estão tentando lhe dizer é que não é aconselhável e nem muito menos fácil, a menos que você queira sacrificar a manutenção.

Várias pessoas já desaconselham a prática, o que não quer dizer que a torne errada, mas é porque realmente já apanharam bastante com tal abordagem.

Resumindo, não é errado é só desaconselhável.

Abs []

[quote=AlexandreGama][quote]
Regras de negócio é o que o cliente quer executar. Se vc não entende o que o cliente quer, não tem como fazer o sistema.
[/quote]

Sim. Regras de negócios sao os problemas que o cliente quer resolver. Em nenhum momento banco de dados entra na conversa. Banco é infra :wink:

Pq? Para estudo ou para distribuição?

Abs![/quote]

Estava estudando ele, mas penso em utilizar isso nas minhas distribuições.
Até agora para sistemas simples a idéia tem funcionando.

Exatamente. O que quero mostrar é que algumas soluções podem ser melhores que outras e vice versa

+1

E infelizmente muitos levam os modelos anêmicos para o design do código. BOLOVOS que até hoje sobrevivem.

Exatamente. Possível é, aconselhável não.

Perfect!

Abs!

[Desviando o tópico]

E por que voce faria isso??? Os Frameworks do mercado não estão atendendo às suas necessidades?
“As suas distribuições” você que dizer nos sistemas que você for desenvolver ou está desenvolvendo? Tem a possibilidade de outro programador colocar a mão nisso? Se sim, de verdade, aconselho fortemente que você repense isso!
Soluções caseiras são aberrações mal projetadas e que atrapalham a vida de qualquer programador. Em nenhum momento estou falando do seu Framework e sim da utilização dele em produção.

[/Desviando o tópico]

Abs!