Quem precisa salvar dados em sessão

Question

i criar um pequeno aplicativo com asp.net MVC Framework. Eu tenho uma pergunta. I construído n-camada estrutura (controlador -> camada de serviço -> camada repositório) de aplicação e criado um Wizzard para recolher a partir dos dados do usuário. Alguns dados que vem a partir do repositório (camada de dados) necessidade de poupar para a próxima etapa (por exemplo, quando premir o botão de usuário de volta no Wizzard), este não é um dado que entrou pelo usuário. Por alguma razão que eu preciso para armazenar em cache esses dados a partir do repositório (para disaplying quando o botão de volta pressionando). Para a minha candidatura eu vou salvar esses dados em sessão e eu não sei quem deve salvar esses dados. De um lado, deve ser uma camada de serviço - e eu preciso enviar sessionstatewrapper a ele. Mas para a lógica de negócio da aplicação - para a camada de serviço eu preciso enviar todos os dados do wizzard e separar esses dados para alguns passos é apenas vista defferent para a recolha de dados e processar esses dados - é obra da camada de apresentação (por exemplo, controlador). Alguma idéia para ajuda?

P.S. Desculpe pelo meu inglês =)

Answer 1

Eu diria que isso é algo que o frontend deve tomar cuidado com isso. Sua camada de serviço não precisa se preocupar com o fato de que esses dados são coletados em um assistente e que é um assistente baseado na web para que o seu frontend é apátrida. Considere o seguinte: o que você teria feito isso era um aplicativo baseado em Windows? Seu "frontend" iria manter o estado para você.

Mas isso é apenas minha $ 0,02 ...

Answer 2

Parece que você tem uma aplicação bastante complexa ali. Como você parece não estar familiarizado com o framework MVC você está usando, eu recomendaria para começar com coisas extremamente simples. Isto significa que, por exemplo, você não salvar os dados até o final. Avise os seus utilizadores e, entretanto, aprender o máximo sobre o MVC você está usando. Quando vocês terão conhecimento suficiente, e então voltar e adicionar essa funcionalidade.

BTW, no MVC:

• M é o modelo, os dados que você buscar a partir de arquivos, bases de dados, stdin, etc.
• V é a vista, a camada de apresentação. Ele exibe os dados, é o frontend.
• C é o Controller, que controla tudo no aplicativo. Ele busca dados do modelo, processa-o, envia-o para a vista, aguarda por uma resposta, recebe a resposta do ponto de vista, processa-lo, age em conformidade.

Meus 2 centavos são de que você deve fazer a cuidar Controlador do Estado do assistente.

Answer 3

É uma exigência que você salve-o em sessão, ou que você salvá-lo na memória no servidor.

No seu caso eu teria usado bloco de aplicação Enterprise Library Caching. Com isso, você pode criar um cache de chave / valor par onde a chave é o ID do usuário eo valor é um objeto que contém as informações que você gostaria de loja.

Usando EntLib você pode acessar as informações da camada em seu aplicativo que faz mais sentido, e não precisa se preocupar quando você tem acesso ao estado da sessão.

Editar

Coloque o armazenamento de dados da sessão no Modelo. O modelo é responsável por cuidar de dados. Os dados View mostra para o usuário e os controles de controlador.

Answer 4

Se você está passando dados e para trás através de um assistente, a primeira coisa que penso é TempData. Este é precisamente um dos seus usos - você precisa persistir alguma coisa para a próxima (ou anterior) somente, cada passo. Claro, desde que TempData usa Session, no final do dia, se você tem uma necessidade de usar Session diretamente, é sempre uma opção.

Este é o tipo de coisa que o Controlador deve ser de gestão. Seu serviço e camadas de repositório deve fornecer o controlador de todos os dados de que necessita, mas o próprio controlador deve ser gerir a persistência de dados em toda a sua assistente. Se você olhar para ele como "dados de vista" para suas páginas do assistente (não sei se isso é representativo de seus dados ou não, mas pode ser) que podem torná-lo mais claro qual nível do sistema deve ser responsável por -lo.