CodeSmith é uma ferramenta ORM viável (ou devo ficar com uma verdadeira ORM) [fechado]
https://stackoverflow.com/questions/583232
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianPergunta
Eu estou comprando para uma ferramenta ORM. Eu estou agonizando sobre a compra de qualquer CodeSmith (que está atualmente disponível com um desconto substancial) versus uma ferramenta ORM.
LINQ to SQL é da minha lista; 2.x SubSonic está fora da lista (I não querem investir nesse beco sem saída sabendo que SubSonic 3.0 está chegando. NHibernate parece EF exagero como faz LLBLGen. Eu avaliada apenas brevemente, mas não conseguir obter rapidamente um quente e macio sensação dela.
Am I pensamento louco que CodeSmith é uma alternativa racional para ORMs off-the-shelf? Will CodeSmith pagar por si mesmo de outras maneiras?
Por favor note que eu estou em nenhuma maneira relacionada com quaisquer fornecedores e isso não é uma questão SO tiro barato apenas por uma questão de geração de ruído produto! Eu estou olhando para o conselho honesto e opiniões sobre CodeSmith como uma ferramenta ORM (com sua fornecido, ou comunidade disponível) modelos.
Solução
Na verdade, o Hibernate é uma boa ferramenta ORM. Mas ele pára lá!
capacidades Código smith pode ser mais do que apenas uma equipe de mapeamento relacional! I usar o código smith para gerar algumas formas de interface do usuário, negócio camadas (templates), camadas de acesso a dados, padrões e assim por diante. Mas para trabalhar com código smith, você pode precisar de uma boa experiência com o projeto do sistema ou utilizar os seus modelos que eu não gosto de usar, mas eu gosto como um exemplo.
abordagem código smith tem uma desvantagem especial; você tem que projetar seu sistema considerando a implementação de banco de dados em primeiro lugar. Hoje em dia, na abordagem de análise de objeto, o sucesso de pessoas na implementação de lógica de negócios e entidades antes de qualquer implementação de banco de dados -. Esquecem-se sobre este
Decisão é difícil; Eu constantemente ler nomes importantes, como Scott W. Ambler, Kent Beck, Robert C. Martin e as pessoas da série Pragmatic Programmers que recomenda ORM ferramenta para acelerar o desenvolvimento. Eles disseram que os desenvolvedores ORM Ferramenta estão preocupados com todos os problemas de banco de dados (pooling, conexões, as especificidades do fornecedor de banco de dados, etc). Então, quando nós temos que projetar camadas de acesso a dados que temos de considerar todos esses aspectos também.
Acredito que essas ferramentas ORM vêm junto com uma sobrecarga. Eu ainda não sei como essas ferramentas seria comportamento em projetos de baixo orçamento (quero dizer, não é bom servidores de hospedagem ou qualquer tipo de recursos compartilhados). Eu vi desenvolvedores inexperientes não tendo isso em conta como eles tentam evangelizar suas ferramentas amados. Mas em projetos java, hibernate já é uma ferramenta generalizada e bem conhecido. Eu não tenho dúvida de que os grandes projectos foi entregue usando esta tecnologia, mas eu vi ninguém e novamente desenvolvedores Java pode precisar de nós (NET) ensinar a construir grandes soluções. (Desculpe, temos de admitir.)
A única coisa que eu recomendo é de considerar o seu contexto. Você está fazendo um novo sistema? Você precisa trabalhar no padrão? Alguma vez você já tentar considerar tais ferramentas de gerador de código e ORM completamente?
eu prefiro código smith porque eu gerar soluções inteiras de uma só vez, e não apenas da camada de acesso de dados. geração de código é muito importante e não é para menos que a Microsoft tem imitado código abordagem smith no studio.net Visual 2008 e assim por diante.
Boa sorte
Outras dicas
Código Smith não é um ORM, é apenas um IDE gerador de código.
Você pode gerar uma DAL usando o código smith baseado fora seu banco de dados, mas que iria derrotar (uma das) os efeitos da utilização de um ORM que é, basicamente, que ele gera o DAL dinamicamente para que você não tem que escrever o código.
Se você está realmente tentando comparar os dois, então talvez você pode obter algum benefício utilizando o código smith, porque você teria o controle absoluto sobre o código que é gerado, mas não tenho a certeza que o benefício seria sobrelevar a desvantagem de o que poderia vir a ser gasto meses para escrever o código smith modelos para gerar uma DAL baseado fora seu banco de dados.
E então você tem que considerar o que acontece quando você faz uma alteração em seu banco de dados, você provavelmente terá de executar código smith e toda construção que você fazê-lo. Um bom ORM lhe permitirá configurar as alterações de banco de dados no esquema e, em seguida, ele irá gerar dinamicamente para que você não precisa se preocupar (tanto) sobre como fazer alterações ao banco de dados.
NHibernate é o caminho a percorrer. É um ORM de nível empresarial. E com a auto-configuração baseada na convenção do FluentNHibernate biblioteca, a configuração é ridiculamente simples se ater a um único convenção (você começa a especificar as convenções, ou existem padrões).
Com NHibernate, seus objetos de domínio são puros C # objetos. Não há classes base estranhas. Nenhum arquivo codegenned que precisam ser atualizados a cada vez que você decidir fazer uma mudança.
Eu uso NetTiers diária e amá-lo. Documentação para ele é uma porcaria, mas tem sido uma poupança de tempo para mim no escritório. Um monte de gente gripe sobre a quantidade de código que produz, mas pelo que eu vi, o código que ele cria é muito mais rápido do que a codificação muito do que mão. Ele também gera todos os sprocs que você vai precisar para o seu coisas básicas CRUD. Os métodos de acesso que ela produz são muito legal, bem como, ficando por todas as suas chaves únicas, chaves estrangeiras e chaves primárias.
Eu acho que o uso de CodeSmith é viável. Mas você deve olhar para os quadros que o utilizam. Tiers Net é uma estrutura de aplicativo que pode ser construído em cima de bater para fora um bom DAL.
Por que algo como LLBLGen ser um exagero? Nós usá-lo no trabalho, e depois de uma curva de aprendizado um pouco íngreme, é muito bom :). Você deve pelo menos dar isso e nhibernate uma tentativa.
Não sei o que isso tem a ver com CodeSmith porém, isso é um CodeGenerator, você pode rolar o seu próprio ORM, mas uma vez que já são bons lá fora, eu não acho que vale a pena o tempo e esforço a menos que queira fazê-lo para fins de aprendizagem.
Vá com NetTiers e .netMVP. NetTiers é um muito bom DAL e .netMVP é um quadro que acaba de ser lançado para a abstração apoio ao nível da interface do usuário. :)
http://community.codesmithtools.com/CodeSmith/m/templates /42499.aspx
Eu costumava LLBLGen há vários anos. Espero que o que eu vi foi corrigido. Olhamos para o SQL in-line que foi produzido e serra, para a seleção de uma linha de dados com a chave primária aprovada em:
SELECT DISTINCT * FROM TABLE WHERE primark_key_id = @primarykey.
Realmente, distinto? Eu sempre pedia para fazer armazenar procs em vez disso, mas o que derrubado pelo líder do projeto. Não estou certo de que o tempo foi salvo por escrever código ineficiente.
