1. Criar problemas
No Struts2, se a interface modeldriven <Model> for implementada, os parâmetros passados poderão ser injetados no modelo, e o modelo poderá ser usado na ação, mas o que devo fazer se houver dois modelos que precisam ser usados na mesma ação? Por exemplo, na seção anterior, concluímos a função de pagamento on -line, mas o pagamento ainda não terminou. Precisamos receber feedback de informações de terceiros. Por exemplo, após o pagamento bem -sucedido, precisamos enviar e -mails e mensagens de texto para o pagador. Portanto, também precisamos obter os parâmetros passados de terceiros no PayAction. Como os parâmetros passados a partir de terceiros são diferentes dos passados por nós, temos que escrever um modelo (backdata) para receber esses parâmetros. Portanto, o problema é que nossa PayAction foi escrita da seguinte forma: PayAction de classe pública estende a Baseaction <SndinData>, isto é, a interface Modeldriven <SkndData> foi implementada na Baseaction. Então, como recebemos outro modelo em uma ação e precisamos lidar com eles de maneira diferente?
Existe uma solução (na verdade, ela não pode ser chamada de solução ... porque não está resolvida ...) que é escrever um modelo e depois deixar o senddata e o backdata herdá -lo, mas o problema é que esses dois modelos não têm nada a fazer, por que você precisa herdar o mesmo modelo? Portanto, esta solução está realmente escapando do problema acima.
Esse problema é bem resolvido no SpringMVC (o SpringMVC realmente não começou a aprender. Se você diz algo errado, corrija -o!) Porque cada método no SpringMVC corresponde a um modelo, em vez de cada ação corresponde a um modelo, o que é conveniente. Eu posso apenas escrever dois métodos na mesma ação, e métodos diferentes lidam com modelos diferentes.
2. Solução para o problema
O STRUTS2 também fornece uma solução para esse problema:
O STRUTS2 armazena muitos mapas no ActionContext, como solicitação, sessão, aplicação etc. mencionados anteriormente. Há também um parametermap, que armazena todos os parâmetros de solicitação da solicitação. Enquanto nossa ação implementar a interface do ParameterAware, podemos obter esse parameterMap. É o mesmo que o Modeldriven. Se implementarmos a interface Modeldriven <Model>, podemos obter o modelo na ação, ou seja, definir um modelo e implementar o método de conjunto.
Ok, agora o problema é fácil de resolver. Os parâmetros de pagamento e os parâmetros retornados são diferentes. Ou seja, os parâmetros que entram no Payacition duas vezes são diferentes, ou seja, os dados instalados no parametermap duas vezes são diferentes. Desde que selecionemos um parâmetro na ação (o parâmetro pode ser distinguido das duas solicitações de solicitações diferentes) como julgamento, saberemos qual modelo deve ser usado para receber os parâmetros (sendData ou backdata). Vamos reescrever o código no PayAction:
@Controller ("PayAction")@scope ("prototype") public class PayAction estende o Baseaction <ject> implementa o parameterAware {// observe que o sendData não pode ser escrito na base herdada acima. Você precisa escrever objeto. Posteriormente, determinaremos qual deles usar // definir um mapa para receber o mapa privado de solicitação <string, string []> parâmetros; @Override public void setParameters (map <string, string []> parâmetros) {this.parameters = parâmetros; } / *No artigo de struts-default.xml, o interceptor ServletConfig é executado antes do Modeldriven; portanto, quando injetarmos o modelo, o parâmetro de solicitação já está disponível, para que possamos usar parâmetros no método getModel () para determinar qual é o uso de parâmetros * /@Override não retorna // dessa maneira, podemos usar esse parâmetro para determinar se ele é pago ou devolvido se (parâmetros.get ("pd_frpid")! = null) {model = new sendData (); } else {model = new BackData (); } Modelo de retorno; } // Método para enviar dados para yibao public string gobank () {// o modelo enviado correspondente: sendData sendData sendData = (sendData) modelo; // A lógica do envio de dados foi implementada na seção anterior ...} // O método de receber dados de retorno public void backbank () {// o modelo Recebido correspondente: modelo backdata backdata = (backdata); // A lógica do manuseio de dados retornados ... ele será implementado posteriormente, // O ponto de conhecimento do Struts2 primeiro lida com várias solicitações de modelo}}3. Fluxo de processamento STRUTS2
Vamos analisar o processo de execução do STRUTS2, que será mais propício para entender os princípios acima. Fluxo de processamento de suportes:
1) Depois de obter a solicitação, primeiro crie o proxy da ação e depois crie a ação ao criar o proxy;
2) Execute 18 interceptores e, em seguida, chame o método de ação após o interceptador ser executado com sucesso;
3) Após a execução do método de ação, 18 interceptores são chamados. Portanto, de acordo com esse processo, sabemos: primeiro crie ação> e depois execute o interceptor (primeiro execute servletconfig, depois execute o Modeldriven, porque o interceptor ServletConfig está equipado na frente do Modeldriven). Portanto, no código acima, podemos usar os dados no parametermap no método getModel () para fazer julgamentos.
Use o seguinte diagrama de tempo simples para representar intuitivamente o fluxo de processamento acima:
Isso mostra o fluxo de processamento da intuição STRUTS2, por isso é fácil entender o processamento acima de várias solicitações de modelo. Nesse ponto, a parte do método do STRUTS2 para lidar com várias solicitações de modelo foi analisada. A seguir, é apresentada uma pequena lógica neste projeto.
4. Melhore o método de receber dados
Uma lógica por trás disso é a implementação da lógica, ou seja, processando os dados retornados. A lógica aqui inclui principalmente: Atualizando o status do pedido (pago, enviado etc.), enviando e -mails, enviando mensagens de texto etc. Primeiro concluiremos o status do pedido de atualização, enviaremos e -mails e enviaremos mensagens de texto para o assunto, e o escreveremos mais tarde.
Primeiro melhore o método backbank ():
public void backbank () {backdata backdata = (modelo backdata); System.out.println (modelo); boolean isok = payService.checkbackdata (backdata); if (isok) {// 1. Atualize o status do pedido, os parâmetros são transmitidos de acordo com a situação no banco de dados, usados para testar ForderService.UpDatestatusbyId (Integer.Valueof (201605006), 2); // 2. Envie um email de acordo com o endereço de e -mail do usuário // 3. Envie um sistema de mensagem de texto do telefone celular.out.println ("---- Sucesso !! -----"); } else {System.out.println ("---- FALSE !!! -----"); }}Em seguida, concluímos o método CheckbackData (BackData) no PayService (a lógica é basicamente a mesma da seção 21):
@Service ("PayService") Public Class PayServiceImpl implementa PayService {// omiti o código irrelevante/*********************************** backdata) {// Anexe string para se preparar para a verificação de criptografia StringBuffer InfoBuffer = new StringBuffer (); infobuffer.append (backdata.getp1_merid ()); infobuffer.append (backdata.getR0_cmd ()); infobuffer.append (backdata.getR1_code ()); infobuffer.append (backdata.getR2_trxid ()); infobuffer.append (backdata.getr3_amt ()); infobuffer.append (backdata.getR4_cur ()); infobuffer.append (backdata.getR5_pid ()); infobuffer.append (backdata.getR6_order ()); infobuffer.append (backdata.getR7_uid ()); infobuffer.append (backdata.getR8_mp ()); infobuffer.append (backdata.getR9_btype ()); retornar infobuffer.toString (); } // criptografar os dados retornados e compará -los com o texto cifrado enviado. Se ok, significa que os dados não foram adulterados. public boolean checkbackdata (backdata backdata) {string jun JunParam = this.joinbackdataparam (backdata); // Obtenha sua própria String CipherText md5 = Digestutil.hmacsign (junçãopparam.toString (), chave); // Comparação do CipherText com o CipherText enviado sobre o retorno md5.equals (backdata.gethmac ()); }}Finalmente, concluímos o método UpdateStatusById em ForderService:
// FordserService Interface Interface pública A ForderService estende o BaseService <storder> {// omiti outros códigos não relacionados ... // Atualize o status do pedido de acordo com o número do pedido public void updateStatusById (Int ID, INTService);} // FORDERSEVICEIMPLETIONSPLETIVIDERIDEIRIDEIRSTERSTERSTERSTERS (ForerService); implementa a ForderService {// omitisse outros códigos não relacionados @Override public void updateStatusbyId (int id, int sid) {string hql = "update forder f set f.status.id =: sid where f where f.id =: id"; getSession (). CreateEquery (HQL) .setInteger ("sid", sid) .setInteger ("id", id) .executeUpdate (); }}Isso permitirá que o status do pedido seja atualizado após o pagamento do cliente.
Link original: http://blog.csdn.net/eson_15/article/details/51465067
O exposto acima é todo o conteúdo deste artigo. Espero que seja útil para o aprendizado de todos e espero que todos apoiem mais o wulin.com.