none
Serialização de objetos RRS feed

  • Pergunta

  • Galera bom dia a todos

    Hoje não é bem uma dúvida de como fazer a serialização, mas queria entender bem o porque de fazer serialização de um objeto vamos la ao que que entedi:

    cenário:

    Criei um componente ASP.Net Server Control, este componente precisa controlar um calendário, este calendário tem uma classe que tem propriedades que são listas de objetos. este objetos são as tasks que devem ser listadas e organizadas no calendario.

    ao iniciar os teste, teve a necessidade de colocar uma tag [Serializable()] para poder gravar o objeto calendario no ViewState, esta tag eu tive que colocar em todas as classe que foram usadas, eu não sabia bem o que esta tag fazia, mas depois eu dei uma pesquisada

    não sei se a definição é essa mesmo que eu entendi:

    serializar cria um arquivo xml com os valores e definições de um objeto, uma classe serializada pode ser transportada para outra aplicação que mesmo que não tenha cido escrita na mesma linguagem.

    mas o pq uma classe precisa ser serializada para ser salva no view state da página?

    achei bem interessante este recorso, se alguem ter alguma documentação sobre o assunto eu agradeço se me enviarem


    obrigado a todos e bom dia!

    Rumo ao MCP
    terça-feira, 7 de julho de 2009 12:42

Respostas

  • Elisson,

    O conceito de serialização, de uma forma mais genérica é pegar uma instância de um objeto e criar uma representação dela que seja possível de transferir através de um meio físico (disco, rede, etc).

    Em outras palavras, vc tem uma instância de um objeto, toda tipadinha, de alguma forma, converte isso numa string, transfere via HTTP e do outro lado desserializa isso de volta no objeto, recuperando ele (de forma fortemente tipada) exatamente os mesmos valores que tinha antes da transferência.

    Esse conceito, pode ser aplicado a vários tipos de objetos e meios de serialização. Por exemplo:

    - Serializar um objeto num xml, gravar em disco, depois ler novamente e recuperar o objeto.
    - Serializar um objeto em JSON, manipular esse objeto em javascript, depois recuperar o objeto.
    - Serializar um objeto em "flash remoting" (coisas realizadas por gateways como o WebORB e fluorine), manipular esse objeto em ActionScript (Adobe Flex), depois desserializar de volta em objetos .Net.

    No caso do ViewState em específico, se vc pendura um objeto no ViewState, o mesmo é serializado para o ViewState e posteriormente desserializado (depende do tipo de viewstate que vc usa). Para os server controls em geral, não são todas as propriedades dele que são serializadas (a instância do Server control, ou seja, o TextBox, o DropDownlist e outros) não são completamente serializados. Apenas o ViewState deles passa por esse processo. As instâncias dos controles são recriadas a cada request.

    No caso do ViewState, se vc usa um state server "inProc", ele não serializa. Somente guarda na memória a instância e recupera posteriormente (pq o request posterior sempre cai na mesma máquina, por isso dá para ser em memória). Se vc tem mais de um web server, automaticamente precisa usar o State Server ou o Sql Server como meio de persistência do ViewState. Nesse caso, ele passará a ser serializado.

    O que precisa-se ter em mente é que nem tudo é serializável. Por exemplo... vc tem um objeto A que referencia um objeto B que referencia novamente o A. Se tentar serializar isso, provavelmente toma um stack overflow (pq o algoritmo de serialização da framework é falho). Dá pra resolver isso de outras formas.

    Vc tem um objeto que tem uma conexão de banco de dados. Como é que se serializa uma conexão de banco de dados? A resposta é: não dá. Então vc precisa "ignorar" esse tipo de propriedade. Por isso a framework força você a realizar anotações do tipo Serializable e NonSerializable em algumas classes, para permitir que você tenha alguma flexibilidade nesse processo.

    A Framework possui classes como BinaryFormatter (para serialização binária, menor, porém impossível de ler por humanos), XmlSerialzer e outras (para serialização em XML) e JSON (acho q na 3.5 mudaram as classes para serializar em JSON).

    É possível aplicar o conceito para outros formatos, inclusive proprietários.


    Abraço,

    Eric
    • Marcado como Resposta Elisson quinta-feira, 9 de julho de 2009 12:49
    terça-feira, 7 de julho de 2009 14:21
  • Olá a todos,

    "No caso do ViewState, se vc usa um state server "inProc", ele não serializa. Somente guarda na memória a instância e recupera posteriormente (pq o request posterior sempre cai na mesma máquina, por isso dá para ser em memória). Se vc tem mais de um web server, automaticamente precisa usar o State Server ou o Sql Server como meio de persistência do ViewState. Nesse caso, ele passará a ser serializado."

    Que eu saiba os métodos de gerenciamento de estado InProc/Sql Server/StateServer são recursos disponíveis para o gerenciamento de estado server-side (em outras palavras, objeto Session) e nada tem a ver com o ViewState.

    []s

    Robson Castilho - MCTS .Net 2.0 Windows/Web Applications [Se o post foi útil, não esqueça de marcá-lo. Obrigado]
    • Marcado como Resposta Elisson quinta-feira, 9 de julho de 2009 12:50
    terça-feira, 7 de julho de 2009 14:39

Todas as Respostas

  • Elisson,

    O conceito de serialização, de uma forma mais genérica é pegar uma instância de um objeto e criar uma representação dela que seja possível de transferir através de um meio físico (disco, rede, etc).

    Em outras palavras, vc tem uma instância de um objeto, toda tipadinha, de alguma forma, converte isso numa string, transfere via HTTP e do outro lado desserializa isso de volta no objeto, recuperando ele (de forma fortemente tipada) exatamente os mesmos valores que tinha antes da transferência.

    Esse conceito, pode ser aplicado a vários tipos de objetos e meios de serialização. Por exemplo:

    - Serializar um objeto num xml, gravar em disco, depois ler novamente e recuperar o objeto.
    - Serializar um objeto em JSON, manipular esse objeto em javascript, depois recuperar o objeto.
    - Serializar um objeto em "flash remoting" (coisas realizadas por gateways como o WebORB e fluorine), manipular esse objeto em ActionScript (Adobe Flex), depois desserializar de volta em objetos .Net.

    No caso do ViewState em específico, se vc pendura um objeto no ViewState, o mesmo é serializado para o ViewState e posteriormente desserializado (depende do tipo de viewstate que vc usa). Para os server controls em geral, não são todas as propriedades dele que são serializadas (a instância do Server control, ou seja, o TextBox, o DropDownlist e outros) não são completamente serializados. Apenas o ViewState deles passa por esse processo. As instâncias dos controles são recriadas a cada request.

    No caso do ViewState, se vc usa um state server "inProc", ele não serializa. Somente guarda na memória a instância e recupera posteriormente (pq o request posterior sempre cai na mesma máquina, por isso dá para ser em memória). Se vc tem mais de um web server, automaticamente precisa usar o State Server ou o Sql Server como meio de persistência do ViewState. Nesse caso, ele passará a ser serializado.

    O que precisa-se ter em mente é que nem tudo é serializável. Por exemplo... vc tem um objeto A que referencia um objeto B que referencia novamente o A. Se tentar serializar isso, provavelmente toma um stack overflow (pq o algoritmo de serialização da framework é falho). Dá pra resolver isso de outras formas.

    Vc tem um objeto que tem uma conexão de banco de dados. Como é que se serializa uma conexão de banco de dados? A resposta é: não dá. Então vc precisa "ignorar" esse tipo de propriedade. Por isso a framework força você a realizar anotações do tipo Serializable e NonSerializable em algumas classes, para permitir que você tenha alguma flexibilidade nesse processo.

    A Framework possui classes como BinaryFormatter (para serialização binária, menor, porém impossível de ler por humanos), XmlSerialzer e outras (para serialização em XML) e JSON (acho q na 3.5 mudaram as classes para serializar em JSON).

    É possível aplicar o conceito para outros formatos, inclusive proprietários.


    Abraço,

    Eric
    • Marcado como Resposta Elisson quinta-feira, 9 de julho de 2009 12:49
    terça-feira, 7 de julho de 2009 14:21
  • Olá a todos,

    "No caso do ViewState, se vc usa um state server "inProc", ele não serializa. Somente guarda na memória a instância e recupera posteriormente (pq o request posterior sempre cai na mesma máquina, por isso dá para ser em memória). Se vc tem mais de um web server, automaticamente precisa usar o State Server ou o Sql Server como meio de persistência do ViewState. Nesse caso, ele passará a ser serializado."

    Que eu saiba os métodos de gerenciamento de estado InProc/Sql Server/StateServer são recursos disponíveis para o gerenciamento de estado server-side (em outras palavras, objeto Session) e nada tem a ver com o ViewState.

    []s

    Robson Castilho - MCTS .Net 2.0 Windows/Web Applications [Se o post foi útil, não esqueça de marcá-lo. Obrigado]
    • Marcado como Resposta Elisson quinta-feira, 9 de julho de 2009 12:50
    terça-feira, 7 de julho de 2009 14:39
  • Robson,

    Tem toda razão... eu confundi completamente dois conceitos que agora que vc apontou eu percebi a besteira que escrevi. Isso que dá fazer as coisas correndo.

    Corrigindo....

    Se vc pendurar um objeto na "Session", no caso das sessions usando StateServer e SQL Server, os objetos pendurados na session são serializados, armazenados por estes meios e na hora de recuperar são novamente desserializados. No estilo de session InProc, não acontece serialização.

    No caso do ViewState, sempre que as propriedades ou objetos são adicionadas ao viewstate elas são serializadas e no momento do postback, desserializadas.

    Apesar da gafe, o conceito de serialização não se altera.


    Abraço,

    Eric
    terça-feira, 7 de julho de 2009 16:15
  • Tranquilo, Eric, acontece com todo mundo.

    []s
    Robson Castilho - MCTS .Net 2.0 Windows/Web Applications [Se o post foi útil, não esqueça de marcá-lo. Obrigado]
    terça-feira, 7 de julho de 2009 20:17
  • So complementando o que foi dito acima ^^

    Se voce olhar o codigo-fonte da pagina, vai ver um hiddenfield chamado ViewState com uma string criptografada... essa string é a string gerada pelo ViewState da pagina criptografada que é postada para a sua propria pagina U.U

    Isso foi so para terminar a explicaçao do Eric :P
    Se não funciona de um jeito, tente de outro totalmente diferente ^_^
    quarta-feira, 8 de julho de 2009 01:03
    Moderador
  • Se voce olhar o codigo-fonte da pagina, vai ver um hiddenfield chamado ViewState com uma string criptografada... essa string é a string gerada pelo ViewState da pagina criptografada que é postada para a sua propria pagina U.U

    Isso foi so para terminar a explicaçao do Eric :P

    :D

    OK, então a complementação da complementação: Os dados da ViewState NÃO ESTÃO CRIPTOGRAFADOS! Eles estão apenas codificados em Base64.
    Muito cuidado ao guardar dados sensíveis, pois qualquer um com um pouquinho de boa vontade consegue converter de volta para texto e ler o conteúdo.

    Abraços,
    Caio Proiete

    PS: Vai lá Rui, pode me mandar dormir que eu mereço! :)



    Caio Proiete Siga-me no Twitter!
    http://www.caioproiete.com
    quarta-feira, 8 de julho de 2009 01:07
    Moderador
  • kkkkk ta tudo bem... na verdade eu nunca tive curiosidade em desconverter para saber se estavam criptografados ou não mesmo :P

    Ja to tao viciado em colocar os dados sensiveis em sessao mesmo... (apesar de ter ouvido uma historia ai de um cara q conseguia acessar esses dados alterando as id de sessao dos cookies.... mas isso fica para outro forum....)


    Se não funciona de um jeito, tente de outro totalmente diferente ^_^
    quarta-feira, 8 de julho de 2009 01:54
    Moderador