Enums x Tabelas de Dados Organizacionais (E mais uma questão besta de design)
832 views
Skip to first unread message
Daniel Moreira Yokoyama
Jun 28, 2010, 1:19:22 PM6/28/10
to dotnetar...@googlegroups.com
Tivemos uma discussão recentemente aqui a respeito de uma implementação que estamos fazendo.
A dúvida é a seguinte:
Uma entidade pode estar em um de 3 status possíveis: Ativo, Inativo, Suspenso.
Dei a sugestão de criarmos um enumerador e usarmos seu código no registro. O Banco ficaria totalmente ignorante a respeito do significado do número na coluna, somente a aplicação saberia o verdadeiro significado.
Alguém sugeriu que criássemos uma tabela organizacional que contenha os registros (Ativo, Inativo, Suspenso) e fizéssemos um relacioamento entre as tabelas. Mas isso faria perder a tipagem na aplicação, ou seja, ao invéis de verificar se Entidade.Status == Status.Ativo, teríamos que fazer Entidade.Status.Descricao == "Ativo".
Outro sugeriu que aplicássemos as duas soluções, usando enum na aplicação, mas mantendo uma tabela relacionada para que "o operador do banco não fique ignorante quanto ao significado da informação". O argumento utilizado por ele é a possibilidade de usarem estes dados em um cubo.
Pessoal, como vocês resolvem esse tipo de cenário (considerando esta possibilidade de usarem um cubo)?
Alexandre Valente
Jun 28, 2010, 1:23:16 PM6/28/10
to dotnetar...@googlegroups.com
Oi Daniel,
No nosso caso fazemos exatamente isto. Tratamos no domíno como enum e criamos uma tabela no banco pra representa-la (a gente custuma nomear as tabelas e colunas de num de uma maneira padronizada, tipo EnumStatus (id int, descricao varchar)). Realmente é uma redundância porém a tabela ajuda em várias situações além do cubo, como por exemplo em extrações e em consultas de grande volume feitas por views e que resultam em XML.
abs,
Alexandre Valente
MCSE+I, MCSD, MDCBA, ITIL, CSM
2010/6/28 Daniel Moreira Yokoyama <moreira....@gmail.com>
--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
Jeferson Araujo
Jun 28, 2010, 4:54:53 PM6/28/10
to dotnetar...@googlegroups.com
Olá Daniel,
Também não sou perito em modelagem, mas acho melhor fazer a tabela e o enum na aplicação, mais por questão de modelagem mesmo... Assino em baixo o que o Alexandre Valente citou...
[]'s
Jeferson Araujo--
"O mal trabalhador culpa suas ferramentas"
Também não sou perito em modelagem, mas acho melhor fazer a tabela e o enum na aplicação, mais por questão de modelagem mesmo... Assino em baixo o que o Alexandre Valente citou...
[]'s
Jeferson Araujo
"O mal trabalhador culpa suas ferramentas"
Pedro Reys
Jun 28, 2010, 5:00:01 PM6/28/10
to dotnetar...@googlegroups.com
Daniel,
Normalmente criamos uma classe base abstrata Enumeration [1], e então sempre que precisamos criar um "enum" criamos uma implementação desta classe [2]. Normalmente deixamos a base de dados agnóstica com relação a essas Enumerations, como você sugeriu. Mais, em um projeto específico, precisamos criar no banco as tabelas refereentes as Enumerations, por um motivo similar ao seu. O que fizemos foi, em nosso script de build, quando era pra fazer deploy pra produção, estas tabelas e o relacionamentos eram criados.
tucaz
Jun 28, 2010, 6:01:24 PM6/28/10
to .Net Architects
Banco de dados, ainda mais em uma aplicação LOB é pra guardar dados.
Código no banco FTW. Se for usar num cubo, estes dados irão passar por
algum tipo de ETL e ai você faria essa "Transformação".
Cada gato no seu cesto.
On Jun 28, 4:00 pm, Pedro Reys <pedror...@gmail.com> wrote:
> Daniel,
>
> Normalmente criamos uma classe base abstrata Enumeration [1], e então sempre
> que precisamos criar um "enum" criamos uma implementação desta classe [2].
> Normalmente deixamos a base de dados agnóstica com relação a essas
> Enumerations, como você sugeriu. Mais, em um projeto específico, precisamos
> criar no banco as tabelas refereentes as Enumerations, por um motivo similar
> ao seu. O que fizemos foi, em nosso script de build, quando era pra fazer
> deploy pra produção, estas tabelas e o relacionamentos eram criados.
>
> 1 -http://bit.ly/c7A1LM
> 2 -http://bit.ly/dhL0nx<http://codecampserver.codeplex.com/SourceControl/changeset/view/4755c...>
> <http://codecampserver.codeplex.com/SourceControl/changeset/view/4755c...>
> - Pedro Reys
>
> 2010/6/28 Alexandre Valente <alexandre.g.vale...@gmail.com>
>
> > 2010/6/28 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
> >> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>
Código no banco FTW. Se for usar num cubo, estes dados irão passar por
algum tipo de ETL e ai você faria essa "Transformação".
Cada gato no seu cesto.
On Jun 28, 4:00 pm, Pedro Reys <pedror...@gmail.com> wrote:
> Daniel,
>
> Normalmente criamos uma classe base abstrata Enumeration [1], e então sempre
> que precisamos criar um "enum" criamos uma implementação desta classe [2].
> Normalmente deixamos a base de dados agnóstica com relação a essas
> Enumerations, como você sugeriu. Mais, em um projeto específico, precisamos
> criar no banco as tabelas refereentes as Enumerations, por um motivo similar
> ao seu. O que fizemos foi, em nosso script de build, quando era pra fazer
> deploy pra produção, estas tabelas e o relacionamentos eram criados.
>
> 1 -http://bit.ly/c7A1LM
> <http://codecampserver.codeplex.com/SourceControl/changeset/view/4755c...>
> - Pedro Reys
>
> 2010/6/28 Alexandre Valente <alexandre.g.vale...@gmail.com>
>
> > Oi Daniel,
>
> > No nosso caso fazemos exatamente isto. Tratamos no domíno como enum e
> > criamos uma tabela no banco pra representa-la (a gente custuma nomear as
> > tabelas e colunas de num de uma maneira padronizada, tipo EnumStatus (id
> > int, descricao varchar)). Realmente é uma redundância porém a tabela ajuda
> > em várias situações além do cubo, como por exemplo em extrações e em
> > consultas de grande volume feitas por views e que resultam em XML.
>
> > abs,
>
> > Alexandre Valente
> > MCSE+I, MCSD, MDCBA, ITIL, CSM
> > agvalente.wordpress.com
> >www.whitefox.com.br<http://www.whitefox.com.br%20/>
> > Oi Daniel,
>
> > No nosso caso fazemos exatamente isto. Tratamos no domíno como enum e
> > criamos uma tabela no banco pra representa-la (a gente custuma nomear as
> > tabelas e colunas de num de uma maneira padronizada, tipo EnumStatus (id
> > int, descricao varchar)). Realmente é uma redundância porém a tabela ajuda
> > em várias situações além do cubo, como por exemplo em extrações e em
> > consultas de grande volume feitas por views e que resultam em XML.
>
> > abs,
>
> > Alexandre Valente
> > MCSE+I, MCSD, MDCBA, ITIL, CSM
> > agvalente.wordpress.com
>
> > 2010/6/28 Daniel Moreira Yokoyama <moreira.yokoy...@gmail.com>
> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > --
> > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para
> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > --
> > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para
Alexandre Valente
Jun 28, 2010, 6:06:03 PM6/28/10
to dotnetar...@googlegroups.com
Oi Tuca,
Na teoria sim. Na prática, fica pouco produtivo. Extrações p. ex. acontecem em qualquer sistema. Se por causa de um purismo vc não colocar isto em banco, vc vai ter uma complexidade adicional em qualquer extração ou tela de consulta mais avançada. Na minha opinião, este é um caso onde mais do que vale dar uma "entortada" nesta separação teórica, os ganhos em produtividade justificam em curto prazo.
abs,
Alexandre Valente
MCSE+I, MCSD, MDCBA, ITIL, CSM
2010/6/28 tucaz <tuc...@gmail.com>
Juan Pedro A. Lopes
Jun 28, 2010, 10:57:20 PM6/28/10
to dotnetar...@googlegroups.com
Defina "tela de consulta mais avançada".
Eu sou da opinião que só quem acessa o banco é a aplicação. Qualquer comunicação deve ser feita por interfaces comuns (de preferência REST). Se você precisa colocar um enum no banco só para fazer uma query "where t.description = 'Available", algo está errado na sua modelagem.
2010/6/28 Alexandre Valente <alexandre...@gmail.com>
Alexandre Valente
Jun 28, 2010, 11:25:10 PM6/28/10
to dotnetar...@googlegroups.com
Bom, a minha opinião é conhecida. Eu não vou sacrificar produtividade simplesmente para fazer algo que teoricamente faria mais sentido. Pega uma tela simples de consulta, onde vc retorna uma lista que que é o resultado de um join de 10 ou mais tabelas. Fazer isto OO é muito pesado, possível, mas pesado (mais difícil de fazer, mais oneroso em termos de recursos computacionais). Fazer isto usando uma "FOR XML" em uma lista ou SP do Sql Server é ultra trivial. Então neste caso (que nem é uma tela tão complexa assim, uma lista com filtros p. ex.), faz todo sentido deixar parte deste processamento no banco.
Claro que é tudo aquilo que já falamos em outras threads, isto depende do cenário, da equipe da aplicação etc. etc.... Nos nossos sistemas, a gente consegue fazer por completo qualquer lista paginada com vários joins, com vários filtros em minutos (poucos!).... E são telas que vão ter pouquissimas linhas de código, ou seja, fácil de fazer, fácil de manter, baixo impacto em performance.... É muito difiícil ir contra um cenário destes, ainda que (heresia das heresias!) a gente esteja usando o banco como apoio! :-).
abs,
Alexandre Valente
MCSE+I, MCSD, MDCBA, ITIL, CSM
Chan Valle
Jun 29, 2010, 5:03:48 AM6/29/10
to .Net Architects
Bem aqui usamos tabelas e enum como Valente falou, mas pq usamos
varias ferramentas de tratamento de dados e extração
E creio que isto facilite no uso de determinadas ferramentas.
Mas no nosso caso cuidamos de varias bases de diferentes sistemas.
E usar um dicionários de dados para descrever certos tipos seria
inviável pelo volume.
On 29 jun, 00:25, Alexandre Valente <alexandre.g.vale...@gmail.com>
wrote:
>
> 2010/6/28 Juan Pedro A. Lopes <juanplo...@gmail.com>
>
> >> 2010/6/28 tucaz <tuca...@gmail.com>
> >>> <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
varias ferramentas de tratamento de dados e extração
E creio que isto facilite no uso de determinadas ferramentas.
Mas no nosso caso cuidamos de varias bases de diferentes sistemas.
E usar um dicionários de dados para descrever certos tipos seria
inviável pelo volume.
On 29 jun, 00:25, Alexandre Valente <alexandre.g.vale...@gmail.com>
wrote:
> Bom, a minha opinião é conhecida. Eu não vou sacrificar produtividade
> simplesmente para fazer algo que teoricamente faria mais sentido. Pega uma
> tela simples de consulta, onde vc retorna uma lista que que é o resultado de
> um join de 10 ou mais tabelas. Fazer isto OO é muito pesado, possível, mas
> pesado (mais difícil de fazer, mais oneroso em termos de recursos
> computacionais). Fazer isto usando uma "FOR XML" em uma lista ou SP do Sql
> Server é ultra trivial. Então neste caso (que nem é uma tela tão complexa
> assim, uma lista com filtros p. ex.), faz todo sentido deixar parte deste
> processamento no banco.
>
> Claro que é tudo aquilo que já falamos em outras threads, isto depende do
> cenário, da equipe da aplicação etc. etc.... Nos nossos sistemas, a gente
> consegue fazer por completo qualquer lista paginada com vários joins, com
> vários filtros em minutos (poucos!).... E são telas que vão ter pouquissimas
> linhas de código, ou seja, fácil de fazer, fácil de manter, baixo impacto em
> performance.... É muito difiícil ir contra um cenário destes, ainda que
> (heresia das heresias!) a gente esteja usando o banco como apoio! :-).
>
> abs,
>
> Alexandre Valente
> MCSE+I, MCSD, MDCBA, ITIL, CSM
> agvalente.wordpress.comwww.whitefox.com.br<http://www.whitefox.com.br%20/>
> simplesmente para fazer algo que teoricamente faria mais sentido. Pega uma
> tela simples de consulta, onde vc retorna uma lista que que é o resultado de
> um join de 10 ou mais tabelas. Fazer isto OO é muito pesado, possível, mas
> pesado (mais difícil de fazer, mais oneroso em termos de recursos
> computacionais). Fazer isto usando uma "FOR XML" em uma lista ou SP do Sql
> Server é ultra trivial. Então neste caso (que nem é uma tela tão complexa
> assim, uma lista com filtros p. ex.), faz todo sentido deixar parte deste
> processamento no banco.
>
> Claro que é tudo aquilo que já falamos em outras threads, isto depende do
> cenário, da equipe da aplicação etc. etc.... Nos nossos sistemas, a gente
> consegue fazer por completo qualquer lista paginada com vários joins, com
> vários filtros em minutos (poucos!).... E são telas que vão ter pouquissimas
> linhas de código, ou seja, fácil de fazer, fácil de manter, baixo impacto em
> performance.... É muito difiícil ir contra um cenário destes, ainda que
> (heresia das heresias!) a gente esteja usando o banco como apoio! :-).
>
> abs,
>
> Alexandre Valente
> MCSE+I, MCSD, MDCBA, ITIL, CSM
>
> 2010/6/28 Juan Pedro A. Lopes <juanplo...@gmail.com>
>
> > Defina "tela de consulta mais avançada".
>
> > Eu sou da opinião que só quem acessa o banco é a aplicação. Qualquer
> > comunicação deve ser feita por interfaces comuns (de preferência REST). Se
> > você precisa colocar um enum no banco só para fazer uma query "where
> > t.description = 'Available", algo está errado na sua modelagem.
>
> > 2010/6/28 Alexandre Valente <alexandre.g.vale...@gmail.com>
> > Defina "tela de consulta mais avançada".
>
> > Eu sou da opinião que só quem acessa o banco é a aplicação. Qualquer
> > comunicação deve ser feita por interfaces comuns (de preferência REST). Se
> > você precisa colocar um enum no banco só para fazer uma query "where
> > t.description = 'Available", algo está errado na sua modelagem.
>
>
> >> Oi Tuca,
>
> >> Na teoria sim. Na prática, fica pouco produtivo. Extrações p. ex.
> >> acontecem em qualquer sistema. Se por causa de um purismo vc não colocar
> >> isto em banco, vc vai ter uma complexidade adicional em qualquer extração ou
> >> tela de consulta mais avançada. Na minha opinião, este é um caso onde mais
> >> do que vale dar uma "entortada" nesta separação teórica, os ganhos em
> >> produtividade justificam em curto prazo.
>
> >> abs,
>
> >> Alexandre Valente
> >> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >> agvalente.wordpress.com
> >>www.whitefox.com.br<http://www.whitefox.com.br%20/>
> >> Oi Tuca,
>
> >> Na teoria sim. Na prática, fica pouco produtivo. Extrações p. ex.
> >> acontecem em qualquer sistema. Se por causa de um purismo vc não colocar
> >> isto em banco, vc vai ter uma complexidade adicional em qualquer extração ou
> >> tela de consulta mais avançada. Na minha opinião, este é um caso onde mais
> >> do que vale dar uma "entortada" nesta separação teórica, os ganhos em
> >> produtividade justificam em curto prazo.
>
> >> abs,
>
> >> Alexandre Valente
> >> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >> agvalente.wordpress.com
>
> >> 2010/6/28 tucaz <tuca...@gmail.com>
>
> >>> > >> Para mais opções visite o grupo em
> >>> > >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>> > > --
> >>> > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>> > > hospedado no Google Groups.
> >>> > > Para postar envie uma mensagem para
> >>> dotnetar...@googlegroups.com
> >>> > > Para sair do grupo envie uma mensagem para
> >>> > > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>
> >>> <dotnetarchitects%2Bunsu...@googlegroups.com<dotnetarchitects%252Buns...@googlegroups.com>
> >>> > >> Para mais opções visite o grupo em
> >>> > >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>> > > --
> >>> > > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>> > > hospedado no Google Groups.
> >>> > > Para postar envie uma mensagem para
> >>> dotnetar...@googlegroups.com
> >>> > > Para sair do grupo envie uma mensagem para
> >>> > > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>
>
> >>> > > Para mais opções visite o grupo em
> >>> > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>> --
> >>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>> hospedado no Google Groups.
> >>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>> Para sair do grupo envie uma mensagem para
> >>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>
> >>> Para mais opções visite o grupo em
> >>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >> --
> >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >> hospedado no Google Groups.
> >> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >> Para sair do grupo envie uma mensagem para
> >> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>
> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > --
> >>> > > Para mais opções visite o grupo em
> >>> > >http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >>> --
> >>> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >>> hospedado no Google Groups.
> >>> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >>> Para sair do grupo envie uma mensagem para
> >>> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>
> >>> Para mais opções visite o grupo em
> >>>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> >> --
> >> Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> >> hospedado no Google Groups.
> >> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> >> Para sair do grupo envie uma mensagem para
> >> dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsu...@googlegroups.com>
> >> Para mais opções visite o grupo em
> >>http://groups.google.com/group/dotnetarchitects?hl=pt-br
>
> > --
> > Kind regards,
> > Juan Lopes
>
> >http://qrcode.juanlopes.net
>
> > --
> > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para
> > Juan Lopes
>
> >http://qrcode.juanlopes.net
>
> > --
> > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para
Juan Pedro A. Lopes
Jun 29, 2010, 7:07:04 AM6/29/10
to dotnetar...@googlegroups.com
Se a sua tela é resultado de uma SQL gigante, você sempre pode deixar a sua aplicação fazer essa SQL. Ou melhor, usar uma (materialized) view -- acho muito mais elegante. Mas ainda acredito que SQLs gigantes são correções de última hora em erros de modelagem.
Aliás, faz algum tempo que tenho tentado substituir (com sucesso) toda busca complexa não-crítica dos sistemas por full-text search com o Lucene. É muito mais prático tanto do ponto de vista do programador quanto do usuário.
2010/6/29 Alexandre Valente <alexandre...@gmail.com>
Alexandre Valente
Jun 29, 2010, 7:13:23 AM6/29/10
to dotnetar...@googlegroups.com
Não precisa ser SQL gigante Juan. Imagina uma aplicação que controla contratos p. ex., Para vc ver uma lista de contratos com filtros, vc tem contratos join cliente, join endereço, join fornecedor, join nota fiscal, left join cancelamento etc... Agora imagina isto com milhares de registros... Isto se aplica a qualquer sistema cujo domino seja minimamente grande.
Como falei, claro que dá pra fazer isto via aplicação ou via OO, mas é muito mais complexo e provavelmente muito menos performático. E em termos de produtividade é muito dificil bater uma Filtro de Domínio -> Restrições em SQL simples (view ou SP) -> XML -> XSLT -> Html..... Eu sei que muita gente acha que isto não é puro OO ou que fere uma religião ou outra.... Mas o dia em que algo gerar esta mesma produtividade, pode ter certeza que vamos considerar! :-).
abs,
Alexandre Valente
MCSE+I, MCSD, MDCBA, ITIL, CSM
2010/6/29 Juan Pedro A. Lopes <juanp...@gmail.com>
Juan Pedro A. Lopes
Jun 29, 2010, 7:29:40 AM6/29/10
to dotnetar...@googlegroups.com
Se o seu problema são só os joins, o Linq to HQL faz isso com maestria. Aliás, HQL e Criteria já fazem isso com maestria há algum tempo.
Alexandre, infelizmente eu não pude ir no encontro onde você mostrou o framework da WhiteFox, mas eu ainda estou bastante curioso com relação a ele. De verdade. :)
2010/6/29 Alexandre Valente <alexandre...@gmail.com>
Alexandre Valente
Jun 29, 2010, 7:36:48 AM6/29/10
to dotnetar...@googlegroups.com
Oi Juan
Então, como falei, é possível, mas com aumento de complexidade. O problema de HQL é que vc teria que gerar um DTO para cada resultado que no final das contas seria serializado em XML para processamento do XSLT. E lembrando que o LINQ do hibernate ainda não é bom o suficiente para vc lidar com queries complexas, então vc teria que escrever o HQL em string mesmo. E não sendo tipado, vc acaba com um monte de strings em código que são mais difíceis de manter do que no proprio banco. E na parte de enums então, trabalhar com HQL é bem complicado pois o HQL trata a enum como int aí vc teria que ter um tipo de mapeamento para achar as descrições. Ou seja, possível, mas muito mais complexo! :-)
Qdo vc quiser, só marcar um chopp. Estamos ali no downtown agora, pq vc não marca uma visita pra conhecer um dia destes?
Vinicius Quaiato
Jun 29, 2010, 7:40:41 AM6/29/10
to dotnetar...@googlegroups.com
Na vdd o Valente está intimado a comparecer em TODOS os núcleos do DNA pelo Brasil pra mostrar esse framework da WhiteFox.
Pow, pra todas as situações o framework tem soluções, hehehehe. Isso sim é que é previsibilidade, adaptabilidade, reúso, manutenabilidade, e todas "ades" que podemos ter \o/
E aí Valente, quando e por onde começa o tour?!
Twitter
Contact me:
vinicius.quaiato
Vinicius Quaiato
http://viniciusquaiato.com
TwitterContact me:
vinicius.quaiato2010/6/29 Alexandre Valente <alexandre...@gmail.com>
Vinicius Quaiato
Jun 29, 2010, 7:45:49 AM6/29/10
to dotnetar...@googlegroups.com
Agora fugindo um pouco deste cenário que o Valente propôs, de queries complexas e parrudas.
No dia-a-dia, para um cenário mais simples, vocês (não só o Valente) têm tratado a questão de enumerations no banco também, abrindo mão dos recursos de enum do framework?
Já pensar nestas queries complexas não seria tentar prever algo que ainda não existe e não é fato no sistema (a não ser que seja realmente requirement)?
Acho enum um pouco complicado também, pois você sempre tem que ir lá, alterar o enum, para disponibilizar um novo valor, o que também não deixa de ser verdade com um mapeamento para o banco, que se for dinâmico para o código, você perde a "potência" de algo tipado.
Então, para os casos "menos complexos", como vocês têm feito?
2010/6/29 Vinicius Quaiato <vinicius...@gmail.com>
Alexandre Valente
Jun 29, 2010, 7:50:50 AM6/29/10
to dotnetar...@googlegroups.com
Só marcar.
Cara, vcs me conhecem... Eu ODEIO perder tempo, e odeio fazer algo repetitivo ou simples e demorar mais do que o mínimo necessário pra isto... (e que não me dê trabalho de manutenção no futuro...). Pura preguiça mesmo... :-).
O framework em .net e em .mvc é recente, mas a sua concepção (antes com o nosso próprio ORM) tem mais de 10 anos (era originalmente em C++)... então tem muita coisa que a gente foi achando soluções simples e quando mais simples e mais efetiva e mais a solução permanece. Esta, de telas de listas para consultas, com Filtros -> SQL -> XML -> XSLT -> HTML é uma das mais antigas e é impressionantemente efetiva (e neste caso o XSTL é padrão, assim vc nem tem que mexer nele). Claro que isto é pro nosso contexto, com SQL Server etc....
Como falei, não é só pra caso complexo não, praticamente todas as nossas telas de listas com filtros usam isto (até nos nossos sistemas mais modernos). E lembrar de criar um registro no banco toda vez que uma enum for alterada em código não é uma tarefa tão dificil assim :-), mas, em um caso em que isto ocorresse com frequencia, poderiamos até automatizar isto no deploy não? No nosso caso não precisa, enums normalmente correspondem a alguma necessidade de negócio, e uma vez definidas, mudam com muito pouca frequencia.
Só marcar. Acho que já está na hora de fazermos mais um evento aqui no Rio... E quem sabe não fazemos aí em SP um encontro, quem sabe na semana da QConn? :-)
abs,
Alexandre Valente
MCSE+I, MCSD, MDCBA, ITIL, CSM
2010/6/29 Vinicius Quaiato <vinicius...@gmail.com>
tucaz
Jun 29, 2010, 8:15:59 AM6/29/10
to .Net Architects
Alexandre, minha opinião também visa produtividade, mas como não
contextualizei acho que não ficou 100% clara.
Esse cenário de manter apenas o código do "enum" no DB é válido quando
usando NHibernate. Se tivermos essa tabela separada ao invés de fazer:
from C in session.Linq<Cliente>
where c.TipoCliente == EnumTipoCliente.VIP
Teriamos que pegar uma instância da classe TipoCliente (já que ela é
uma entidade em outra tabela) e usar pra comparar na query ou sei lá
onde. Dessa forma a consulta ficaria mais lenta (porque teriamos que
buscar mais um cara no banco) e mais chata de fazer.
Como o NH seta o enum na classe quando ele está carregando, fica 100x
mais fácil fazer usando só o enum sem manter a tabela de domínio (com
as descrições no banco).
Att.,
Tuca
On Jun 29, 8:50 am, Alexandre Valente <alexandre.g.vale...@gmail.com>
wrote:
> agvalente.wordpress.comwww.whitefox.com.br<http://www.whitefox.com.br%20/>
>
> 2010/6/29 Vinicius Quaiato <vinicius.quai...@gmail.com>
> >http://viniciusquaiato.com
>
> > My profiles: Twitter <http://twitter.com/vquaiato>
>
> >> 2010/6/29 Juan Pedro A. Lopes <juanplo...@gmail.com>
>
> >>>> 2010/6/29 Juan Pedro A. Lopes <juanplo...@gmail.com>
>
> >>>>>> 2010/6/28 Juan Pedro A. Lopes <juanplo...@gmail.com>
>
> read more »
contextualizei acho que não ficou 100% clara.
Esse cenário de manter apenas o código do "enum" no DB é válido quando
usando NHibernate. Se tivermos essa tabela separada ao invés de fazer:
from C in session.Linq<Cliente>
where c.TipoCliente == EnumTipoCliente.VIP
Teriamos que pegar uma instância da classe TipoCliente (já que ela é
uma entidade em outra tabela) e usar pra comparar na query ou sei lá
onde. Dessa forma a consulta ficaria mais lenta (porque teriamos que
buscar mais um cara no banco) e mais chata de fazer.
Como o NH seta o enum na classe quando ele está carregando, fica 100x
mais fácil fazer usando só o enum sem manter a tabela de domínio (com
as descrições no banco).
Att.,
Tuca
On Jun 29, 8:50 am, Alexandre Valente <alexandre.g.vale...@gmail.com>
wrote:
>
> 2010/6/29 Vinicius Quaiato <vinicius.quai...@gmail.com>
>
> > Na vdd o Valente está intimado a comparecer em TODOS os núcleos do DNA pelo
> > Brasil pra mostrar esse framework da WhiteFox.
>
> > Pow, pra todas as situações o framework tem soluções, hehehehe. Isso sim é
> > que é previsibilidade, adaptabilidade, reúso, manutenabilidade, e todas
> > "ades" que podemos ter \o/
>
> > E aí Valente, quando e por onde começa o tour?!
>
> > *Vinicius Quaiato*
> > Na vdd o Valente está intimado a comparecer em TODOS os núcleos do DNA pelo
> > Brasil pra mostrar esse framework da WhiteFox.
>
> > Pow, pra todas as situações o framework tem soluções, hehehehe. Isso sim é
> > que é previsibilidade, adaptabilidade, reúso, manutenabilidade, e todas
> > "ades" que podemos ter \o/
>
> > E aí Valente, quando e por onde começa o tour?!
>
> >http://viniciusquaiato.com
>
> > My profiles: Twitter <http://twitter.com/vquaiato>
> > Contact me: [image: Google Talk/]vinicius.quaiato
>
> > 2010/6/29 Alexandre Valente <alexandre.g.vale...@gmail.com>
>
>
> >> Oi Juan
>
> >> Então, como falei, é possível, mas com aumento de complexidade. O problema
> >> de HQL é que vc teria que gerar um DTO para cada resultado que no final das
> >> contas seria serializado em XML para processamento do XSLT. E lembrando que
> >> o LINQ do hibernate ainda não é bom o suficiente para vc lidar com queries
> >> complexas, então vc teria que escrever o HQL em string mesmo. E não sendo
> >> tipado, vc acaba com um monte de strings em código que são mais difíceis de
> >> manter do que no proprio banco. E na parte de enums então, trabalhar com HQL
> >> é bem complicado pois o HQL trata a enum como int aí vc teria que ter um
> >> tipo de mapeamento para achar as descrições. Ou seja, possível, mas muito
> >> mais complexo! :-)
>
> >> Qdo vc quiser, só marcar um chopp. Estamos ali no downtown agora, pq vc
> >> não marca uma visita pra conhecer um dia destes?
>
> >> abs,
>
> >> Alexandre Valente
> >> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >> agvalente.wordpress.com
> >>www.whitefox.com.br<http://www.whitefox.com.br%20/>
> >> Oi Juan
>
> >> Então, como falei, é possível, mas com aumento de complexidade. O problema
> >> de HQL é que vc teria que gerar um DTO para cada resultado que no final das
> >> contas seria serializado em XML para processamento do XSLT. E lembrando que
> >> o LINQ do hibernate ainda não é bom o suficiente para vc lidar com queries
> >> complexas, então vc teria que escrever o HQL em string mesmo. E não sendo
> >> tipado, vc acaba com um monte de strings em código que são mais difíceis de
> >> manter do que no proprio banco. E na parte de enums então, trabalhar com HQL
> >> é bem complicado pois o HQL trata a enum como int aí vc teria que ter um
> >> tipo de mapeamento para achar as descrições. Ou seja, possível, mas muito
> >> mais complexo! :-)
>
> >> Qdo vc quiser, só marcar um chopp. Estamos ali no downtown agora, pq vc
> >> não marca uma visita pra conhecer um dia destes?
>
> >> abs,
>
> >> Alexandre Valente
> >> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >> agvalente.wordpress.com
>
> >> 2010/6/29 Juan Pedro A. Lopes <juanplo...@gmail.com>
>
> >>> Se o seu problema são só os joins, o Linq to HQL faz isso com maestria.
> >>> Aliás, HQL e Criteria já fazem isso com maestria há algum tempo.
>
> >>> Alexandre, infelizmente eu não pude ir no encontro onde você mostrou o
> >>> framework da WhiteFox, mas eu ainda estou bastante curioso com relação a
> >>> ele. De verdade. :)
>
> >>> 2010/6/29 Alexandre Valente <alexandre.g.vale...@gmail.com>
> >>> Se o seu problema são só os joins, o Linq to HQL faz isso com maestria.
> >>> Aliás, HQL e Criteria já fazem isso com maestria há algum tempo.
>
> >>> Alexandre, infelizmente eu não pude ir no encontro onde você mostrou o
> >>> framework da WhiteFox, mas eu ainda estou bastante curioso com relação a
> >>> ele. De verdade. :)
>
>
> >>>> Não precisa ser SQL gigante Juan. Imagina uma aplicação que controla
> >>>> contratos p. ex., Para vc ver uma lista de contratos com filtros, vc tem
> >>>> contratos join cliente, join endereço, join fornecedor, join nota fiscal,
> >>>> left join cancelamento etc... Agora imagina isto com milhares de
> >>>> registros... Isto se aplica a qualquer sistema cujo domino seja minimamente
> >>>> grande.
>
> >>>> Como falei, claro que dá pra fazer isto via aplicação ou via OO, mas é
> >>>> muito mais complexo e provavelmente muito menos performático. E em termos de
> >>>> produtividade é muito dificil bater uma Filtro de Domínio -> Restrições em
> >>>> SQL simples (view ou SP) -> XML -> XSLT -> Html..... Eu sei que muita gente
> >>>> acha que isto não é puro OO ou que fere uma religião ou outra.... Mas o dia
> >>>> em que algo gerar esta mesma produtividade, pode ter certeza que vamos
> >>>> considerar! :-).
>
> >>>> abs,
>
> >>>> Alexandre Valente
> >>>> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >>>> agvalente.wordpress.com
> >>>>www.whitefox.com.br<http://www.whitefox.com.br%20/>
> >>>> Não precisa ser SQL gigante Juan. Imagina uma aplicação que controla
> >>>> contratos p. ex., Para vc ver uma lista de contratos com filtros, vc tem
> >>>> contratos join cliente, join endereço, join fornecedor, join nota fiscal,
> >>>> left join cancelamento etc... Agora imagina isto com milhares de
> >>>> registros... Isto se aplica a qualquer sistema cujo domino seja minimamente
> >>>> grande.
>
> >>>> Como falei, claro que dá pra fazer isto via aplicação ou via OO, mas é
> >>>> muito mais complexo e provavelmente muito menos performático. E em termos de
> >>>> produtividade é muito dificil bater uma Filtro de Domínio -> Restrições em
> >>>> SQL simples (view ou SP) -> XML -> XSLT -> Html..... Eu sei que muita gente
> >>>> acha que isto não é puro OO ou que fere uma religião ou outra.... Mas o dia
> >>>> em que algo gerar esta mesma produtividade, pode ter certeza que vamos
> >>>> considerar! :-).
>
> >>>> abs,
>
> >>>> Alexandre Valente
> >>>> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >>>> agvalente.wordpress.com
>
> >>>> 2010/6/29 Juan Pedro A. Lopes <juanplo...@gmail.com>
>
> >>>>> Se a sua tela é resultado de uma SQL gigante, você sempre pode deixar
> >>>>> a sua aplicação fazer essa SQL. Ou melhor, usar uma (materialized) view --
> >>>>> acho muito mais elegante. Mas ainda acredito que SQLs gigantes são correções
> >>>>> de última hora em erros de modelagem.
>
> >>>>> Aliás, faz algum tempo que tenho tentado substituir (com sucesso) toda
> >>>>> busca complexa não-crítica dos sistemas por full-text search com o Lucene. É
> >>>>> muito mais prático tanto do ponto de vista do programador quanto do usuário.
>
> >>>>> 2010/6/29 Alexandre Valente <alexandre.g.vale...@gmail.com>
> >>>>> Se a sua tela é resultado de uma SQL gigante, você sempre pode deixar
> >>>>> a sua aplicação fazer essa SQL. Ou melhor, usar uma (materialized) view --
> >>>>> acho muito mais elegante. Mas ainda acredito que SQLs gigantes são correções
> >>>>> de última hora em erros de modelagem.
>
> >>>>> Aliás, faz algum tempo que tenho tentado substituir (com sucesso) toda
> >>>>> busca complexa não-crítica dos sistemas por full-text search com o Lucene. É
> >>>>> muito mais prático tanto do ponto de vista do programador quanto do usuário.
>
>
> >>>>> Bom, a minha opinião é conhecida. Eu não vou sacrificar produtividade
> >>>>>> simplesmente para fazer algo que teoricamente faria mais sentido. Pega uma
> >>>>>> tela simples de consulta, onde vc retorna uma lista que que é o resultado de
> >>>>>> um join de 10 ou mais tabelas. Fazer isto OO é muito pesado, possível, mas
> >>>>>> pesado (mais difícil de fazer, mais oneroso em termos de recursos
> >>>>>> computacionais). Fazer isto usando uma "FOR XML" em uma lista ou SP do Sql
> >>>>>> Server é ultra trivial. Então neste caso (que nem é uma tela tão complexa
> >>>>>> assim, uma lista com filtros p. ex.), faz todo sentido deixar parte deste
> >>>>>> processamento no banco.
>
> >>>>>> Claro que é tudo aquilo que já falamos em outras threads, isto depende
> >>>>>> do cenário, da equipe da aplicação etc. etc.... Nos nossos sistemas, a gente
> >>>>>> consegue fazer por completo qualquer lista paginada com vários joins, com
> >>>>>> vários filtros em minutos (poucos!).... E são telas que vão ter pouquissimas
> >>>>>> linhas de código, ou seja, fácil de fazer, fácil de manter, baixo impacto em
> >>>>>> performance.... É muito difiícil ir contra um cenário destes, ainda que
> >>>>>> (heresia das heresias!) a gente esteja usando o banco como apoio! :-).
>
> >>>>>> abs,
>
> >>>>>> Alexandre Valente
> >>>>>> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >>>>>> agvalente.wordpress.com
> >>>>>>www.whitefox.com.br<http://www.whitefox.com.br%20/>
> >>>>> Bom, a minha opinião é conhecida. Eu não vou sacrificar produtividade
> >>>>>> simplesmente para fazer algo que teoricamente faria mais sentido. Pega uma
> >>>>>> tela simples de consulta, onde vc retorna uma lista que que é o resultado de
> >>>>>> um join de 10 ou mais tabelas. Fazer isto OO é muito pesado, possível, mas
> >>>>>> pesado (mais difícil de fazer, mais oneroso em termos de recursos
> >>>>>> computacionais). Fazer isto usando uma "FOR XML" em uma lista ou SP do Sql
> >>>>>> Server é ultra trivial. Então neste caso (que nem é uma tela tão complexa
> >>>>>> assim, uma lista com filtros p. ex.), faz todo sentido deixar parte deste
> >>>>>> processamento no banco.
>
> >>>>>> Claro que é tudo aquilo que já falamos em outras threads, isto depende
> >>>>>> do cenário, da equipe da aplicação etc. etc.... Nos nossos sistemas, a gente
> >>>>>> consegue fazer por completo qualquer lista paginada com vários joins, com
> >>>>>> vários filtros em minutos (poucos!).... E são telas que vão ter pouquissimas
> >>>>>> linhas de código, ou seja, fácil de fazer, fácil de manter, baixo impacto em
> >>>>>> performance.... É muito difiícil ir contra um cenário destes, ainda que
> >>>>>> (heresia das heresias!) a gente esteja usando o banco como apoio! :-).
>
> >>>>>> abs,
>
> >>>>>> Alexandre Valente
> >>>>>> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >>>>>> agvalente.wordpress.com
>
> >>>>>> 2010/6/28 Juan Pedro A. Lopes <juanplo...@gmail.com>
>
> >>>>>>> Defina "tela de consulta mais avançada".
>
> >>>>>>> Eu sou da opinião que só quem acessa o banco é a aplicação. Qualquer
> >>>>>>> comunicação deve ser feita por interfaces comuns (de preferência REST). Se
> >>>>>>> você precisa colocar um enum no banco só para fazer uma query "where
> >>>>>>> t.description = 'Available", algo está errado na sua modelagem.
>
> >>>>>>> 2010/6/28 Alexandre Valente <alexandre.g.vale...@gmail.com>
> >>>>>>> Defina "tela de consulta mais avançada".
>
> >>>>>>> Eu sou da opinião que só quem acessa o banco é a aplicação. Qualquer
> >>>>>>> comunicação deve ser feita por interfaces comuns (de preferência REST). Se
> >>>>>>> você precisa colocar um enum no banco só para fazer uma query "where
> >>>>>>> t.description = 'Available", algo está errado na sua modelagem.
>
>
> >>>>>>>> Oi Tuca,
>
> >>>>>>>> Na teoria sim. Na prática, fica pouco produtivo. Extrações p. ex.
> >>>>>>>> acontecem em qualquer sistema. Se por causa de um purismo vc não colocar
> >>>>>>>> isto em banco, vc vai ter uma complexidade adicional em qualquer extração ou
> >>>>>>>> tela de consulta mais avançada. Na minha opinião, este é um caso onde mais
> >>>>>>>> do que vale dar uma "entortada" nesta separação teórica, os ganhos em
> >>>>>>>> produtividade justificam em curto prazo.
>
> >>>>>>>> abs,
>
> >>>>>>>> Alexandre Valente
> >>>>>>>> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >>>>>>>> agvalente.wordpress.com
> >>>>>>>> Oi Tuca,
>
> >>>>>>>> Na teoria sim. Na prática, fica pouco produtivo. Extrações p. ex.
> >>>>>>>> acontecem em qualquer sistema. Se por causa de um purismo vc não colocar
> >>>>>>>> isto em banco, vc vai ter uma complexidade adicional em qualquer extração ou
> >>>>>>>> tela de consulta mais avançada. Na minha opinião, este é um caso onde mais
> >>>>>>>> do que vale dar uma "entortada" nesta separação teórica, os ganhos em
> >>>>>>>> produtividade justificam em curto prazo.
>
> >>>>>>>> abs,
>
> >>>>>>>> Alexandre Valente
> >>>>>>>> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >>>>>>>> agvalente.wordpress.com
> >>>>>>>>www.whitefox.com.br<http://www.whitefox.com.br%20/>
>
> >>>>>>>> 2010/6/28 tucaz <tuca...@gmail.com>
>
>
> >>>>>>>> 2010/6/28 tucaz <tuca...@gmail.com>
>
> >>>>>>>> Banco de dados, ainda mais em uma aplicação LOB é pra guardar dados.
> >>>>>>>>> Código no banco FTW. Se for usar num cubo, estes dados irão passar
> >>>>>>>>> por
> >>>>>>>>> algum tipo de ETL e ai você faria essa "Transformação".
>
> >>>>>>>>> Cada gato no seu cesto.
>
> >>>>>>>>> On Jun 28, 4:00 pm, Pedro Reys <pedror...@gmail.com> wrote:
> >>>>>>>>> > Daniel,
>
> >>>>>>>>> > Normalmente criamos uma classe base abstrata Enumeration [1], e
> >>>>>>>>> então sempre
> >>>>>>>>> > que precisamos criar um "enum" criamos uma implementação desta
> >>>>>>>>> classe [2].
> >>>>>>>>> > Normalmente deixamos a base de dados agnóstica com relação a
> >>>>>>>>> essas
> >>>>>>>>> > Enumerations, como você sugeriu. Mais, em um projeto específico,
> >>>>>>>>> precisamos
> >>>>>>>>> > criar no banco as tabelas refereentes as Enumerations, por um
> >>>>>>>>> motivo similar
> >>>>>>>>> > ao seu. O que fizemos foi, em nosso script de build, quando era
> >>>>>>>>> pra fazer
> >>>>>>>>> > deploy pra produção, estas tabelas e o relacionamentos eram
> >>>>>>>>> criados.
>
> >>>>>>>>> > 1 -http://bit.ly/c7A1LM
> >>>>>>>>> > 2 -http://bit.ly/dhL0nx<
> >>>>>>>>> Código no banco FTW. Se for usar num cubo, estes dados irão passar
> >>>>>>>>> por
> >>>>>>>>> algum tipo de ETL e ai você faria essa "Transformação".
>
> >>>>>>>>> Cada gato no seu cesto.
>
> >>>>>>>>> On Jun 28, 4:00 pm, Pedro Reys <pedror...@gmail.com> wrote:
> >>>>>>>>> > Daniel,
>
> >>>>>>>>> > Normalmente criamos uma classe base abstrata Enumeration [1], e
> >>>>>>>>> então sempre
> >>>>>>>>> > que precisamos criar um "enum" criamos uma implementação desta
> >>>>>>>>> classe [2].
> >>>>>>>>> > Normalmente deixamos a base de dados agnóstica com relação a
> >>>>>>>>> essas
> >>>>>>>>> > Enumerations, como você sugeriu. Mais, em um projeto específico,
> >>>>>>>>> precisamos
> >>>>>>>>> > criar no banco as tabelas refereentes as Enumerations, por um
> >>>>>>>>> motivo similar
> >>>>>>>>> > ao seu. O que fizemos foi, em nosso script de build, quando era
> >>>>>>>>> pra fazer
> >>>>>>>>> > deploy pra produção, estas tabelas e o relacionamentos eram
> >>>>>>>>> criados.
>
> >>>>>>>>> > 1 -http://bit.ly/c7A1LM
> >>>>>>>>> > 2 -http://bit.ly/dhL0nx<
> >>>>>>>>>http://codecampserver.codeplex.com/SourceControl/changeset/view/4755c..
> >>>>>>>>> .>
> >>>>>>>>> > <
> >>>>>>>>>http://codecampserver.codeplex.com/SourceControl/changeset/view/4755c..
> >>>>>>>>> .>
> >>>>>>>>> .>
> >>>>>>>>> > <
> >>>>>>>>>http://codecampserver.codeplex.com/SourceControl/changeset/view/4755c..
> >>>>>>>>> .>
> >>>>>>>>> > - Pedro Reys
>
> >>>>>>>>> > 2010/6/28 Alexandre Valente <alexandre.g.vale...@gmail.com>
>
> >>>>>>>>> > > Oi Daniel,
>
> >>>>>>>>> > > No nosso caso fazemos exatamente isto. Tratamos no domíno como
> >>>>>>>>> enum e
> >>>>>>>>> > > criamos uma tabela no banco pra
>
> ...
>
> >>>>>>>>> > 2010/6/28 Alexandre Valente <alexandre.g.vale...@gmail.com>
>
> >>>>>>>>> > > Oi Daniel,
>
> >>>>>>>>> > > No nosso caso fazemos exatamente isto. Tratamos no domíno como
> >>>>>>>>> enum e
> >>>>>>>>> > > criamos uma tabela no banco pra
>
>
> read more »
Alexandre Valente
Jun 29, 2010, 8:19:38 AM6/29/10
to dotnetar...@googlegroups.com
Exato. Não se se ficou claro pra todos: a forma que usamos é a ENUM no domíno. O que fazemos é criar uma tabela (que não é usada pelo hibernate) e que contem os registros equivalentes à enum, simplesmente para facilitar queries. De maneira nenhuma faz sentido usar o NH para carregar a tabela de enum como se fosse uma entidade.
abs,
Alexandre Valente
MCSE+I, MCSD, MDCBA, ITIL, CSM
2010/6/29 tucaz <tuc...@gmail.com>
--
Paulo Silva
Jun 29, 2010, 9:02:00 AM6/29/10
to dotnetar...@googlegroups.com
Bom dia!
--
Paulo Silva
{
Homem.Eterno = Acao.Notavel;
}
Eu já trabalhei em projetos que usávamos uma tabela de domínios. Dentro desta tabela temos um código de grupo (por exemplo 1 - Grupo de situação do pedido), um código e uma descrição para o domínio (1 - pedido criado). Com isso criado, temos um código na tabela principal (por exemplo a tabela de pedidos) que faz referência ao domínio.
Gosto bastante desta implementação por atender nos dois sentidos da solução (e ainda fizemos um Wrapper para cada item do enum, pegando a descrição do banco de dados, tornando a exibição para o usuário na APLICAÇÃO mais amigável.)
2010/6/28 Daniel Moreira Yokoyama <moreira....@gmail.com>
Tivemos uma discussão recentemente aqui a respeito de uma implementação que estamos fazendo.
--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br
--
Paulo Silva
{
Homem.Eterno = Acao.Notavel;
}
Reply all
Reply to author
Forward
0 new messages