DUVIDA OOP CAMADAS
Entity Framework , NHibernate e outros ORMs, são coisa linda de Deus. Depois que vc usa, não quer mais saber de digitar SQL no código.
Ok acho que estou entendendo, quer dizer que usando um ORM qualquer eu deixo de escrever os acessos (minha classe DAL) ao banco (SQL Express) e uso a Classe Entity criada pelo frameworks, certo?
Agora as dúvidas:
1- O Entity Framework (EF) só funciona se for incluÃda a referência ao banco dentro da IDE do VS? Pergunto porque não posso criar a conexão embutida na IDE, como và em todos os artigos e exemplos que pesquisei, pois meu programa não é para uso próprio, mas para distribuição e cada cliente terá sua estrutura de rede, servidor SQL e mapeamentos. Assim a conexão tem que ser via código. Isso é possÃvel?
2- Tenho o VS 2008 PRO SP1 e SQL Express 2005. Vi que tem dezenas de ORM diferentes no mercado. Também và que certas tecnologias estão sendo abandonadas como o Linq To SQL.
Alguém poderia indicar então qual é:
- mais estável
- mais confiável,
- melhor performance,
- não esteja descontinuada e
- fácil de trabalhar para um iniciante em .Net?
3- Vi que ao incluir um objeto Entity Data Model ele cria a estrutura do banco igual ao próprio banco. Agora se futuramente o programa em produção em clientes diferenes tiver de alterar estrutura do banco, eu mando o script de altualização ao TI DBA, como ficaria o código do meu sistema para ser atualizado?
Digo, após fazer a mudança no banco, o Entity Atualiza sozinho? Tem que executar algum comando de atualização para ele incorporar a nova estrutura?
4- Qual a diferença entre Entity, Ling To SQL e NHibernate ?
KERPLUNK só um comentário sobre sua explicação de [Ô]... caso você queira encapsular isso para colocar em um webservice para que um cliente possa integrar uma outra aplicação(de outra pessoa) ...[Ô] Quando se usa ofuscadores tudo é renomeado e criptografado. Com isso acredito que seja impossÃvel usar uma aplicação ofuscada com outra externa. Tanto que là da obrigatoriedade de se ofuscar toda uma solução junta para distribuição, pois se ofuscar partes da aplicação, não seria possÃvel usá-las depois. Não fiz teste nesse sentido.
Agora as dúvidas:
1- O Entity Framework (EF) só funciona se for incluÃda a referência ao banco dentro da IDE do VS? Pergunto porque não posso criar a conexão embutida na IDE, como và em todos os artigos e exemplos que pesquisei, pois meu programa não é para uso próprio, mas para distribuição e cada cliente terá sua estrutura de rede, servidor SQL e mapeamentos. Assim a conexão tem que ser via código. Isso é possÃvel?
2- Tenho o VS 2008 PRO SP1 e SQL Express 2005. Vi que tem dezenas de ORM diferentes no mercado. Também và que certas tecnologias estão sendo abandonadas como o Linq To SQL.
Alguém poderia indicar então qual é:
- mais estável
- mais confiável,
- melhor performance,
- não esteja descontinuada e
- fácil de trabalhar para um iniciante em .Net?
3- Vi que ao incluir um objeto Entity Data Model ele cria a estrutura do banco igual ao próprio banco. Agora se futuramente o programa em produção em clientes diferenes tiver de alterar estrutura do banco, eu mando o script de altualização ao TI DBA, como ficaria o código do meu sistema para ser atualizado?
Digo, após fazer a mudança no banco, o Entity Atualiza sozinho? Tem que executar algum comando de atualização para ele incorporar a nova estrutura?
4- Qual a diferença entre Entity, Ling To SQL e NHibernate ?
KERPLUNK só um comentário sobre sua explicação de [Ô]... caso você queira encapsular isso para colocar em um webservice para que um cliente possa integrar uma outra aplicação(de outra pessoa) ...[Ô] Quando se usa ofuscadores tudo é renomeado e criptografado. Com isso acredito que seja impossÃvel usar uma aplicação ofuscada com outra externa. Tanto que là da obrigatoriedade de se ofuscar toda uma solução junta para distribuição, pois se ofuscar partes da aplicação, não seria possÃvel usá-las depois. Não fiz teste nesse sentido.
1 - Bem, deve levar em conta que o banco de dados deve ter a mesma estrutura. Então você cria um objeto do EF(Entity Framework) normalmente e a string de conexão dele pode ser alterada por código, frisando: A estrutura do banco deve ser a mesma.
2 - Entity Framework
3 - Sim, a string de conexão(tecnicamente chamada de pseudo-string), pode ser alterada via código, mas a estrutura do banco deve ser a mesma. Então, se tem atualização no banco, faça-a na sua máquina, atualize o objeto do EF, repasse as alterações do banco para o cliente e só então o sistema/DLL
4 - Linq2SQL não é um ORM, é uma pseudo-linguagem, desenhada para tentar suprimir a necessidade de objeto separado para trabalhar com dados do banco. EF e NHibernate(ECA!!!) são ORM[ô]s
Ao último comentário: Ao se fazer uma [Ô]biblioteca[Ô] da sua aplicação(com suas DAL, Entidades e talz) totalmente independente, você pode compilar ofuscado e criar um webservice com referência à essa DLL compilada e já ofuscada, então, o WebService em si, não precisa ofuscar, ele não vai ter nada de [Ô]Código[Ô]. Além disso, se for um webservice, somente com acesso total ao server se vai poder pegar as DLL para [Ô]descompilar[Ô]
2 - Entity Framework
3 - Sim, a string de conexão(tecnicamente chamada de pseudo-string), pode ser alterada via código, mas a estrutura do banco deve ser a mesma. Então, se tem atualização no banco, faça-a na sua máquina, atualize o objeto do EF, repasse as alterações do banco para o cliente e só então o sistema/DLL
4 - Linq2SQL não é um ORM, é uma pseudo-linguagem, desenhada para tentar suprimir a necessidade de objeto separado para trabalhar com dados do banco. EF e NHibernate(ECA!!!) são ORM[ô]s
Ao último comentário: Ao se fazer uma [Ô]biblioteca[Ô] da sua aplicação(com suas DAL, Entidades e talz) totalmente independente, você pode compilar ofuscado e criar um webservice com referência à essa DLL compilada e já ofuscada, então, o WebService em si, não precisa ofuscar, ele não vai ter nada de [Ô]Código[Ô]. Além disso, se for um webservice, somente com acesso total ao server se vai poder pegar as DLL para [Ô]descompilar[Ô]
Tópico encerrado , respostas não são mais permitidas