Springbank Development Log Redesign action call service parameter passing using generics to resolve type conversion problems

Before the request arrives at the controller, the arguments passed to the action are not encapsulated, which is a map. Then when the action calls the service again, the parameters passed are also map

@Controller  Public class extends basecontroller{    = "Deposit")    public  Map Deposit (map request) {        map Map = Callservice (servicedict.depositservice, request);        return map;     }}

But when I was making a deposit deal, I vaguely felt that it was a problem, because in action it was completely impossible to see the important information such as the payer's payee amount and so on, although the information actually passed through a series of interceptors before invoking the service, but when it reached the service, The parameter again from the map get again, feel very uncomfortable, just like the original data is not verified.

So I think that when the action invokes the service, the parameters should be encapsulated in a special request parameter class.

// Day Cut    @TransactionMapping (transaction = "Nextaccountingdate")    public  Map nextaccountingdate ( Map request) {        = Callservice (Servicedict.nextaccountingdateservice,new  Nextaccountingdaterequest ());         return map;    }

In the case of a day-cut transaction, I have a nextaccountingdaterequest that encapsulates the parameters required for the service (in fact, this transaction has no parameters, just an example)

 Public Abstract classService {        PrivateList<interceptor>interceptorlist; @SuppressWarnings ("Rawtypes")     Public AbstractMap Execute (Object request);  PublicList<interceptor>getinterceptorlist () {returninterceptorlist; }     Public voidSetinterceptorlist (list<interceptor>interceptorlist) {         This. interceptorlist =interceptorlist; }}

But I call the service in a reflective way, and all the service inherits the abstract class service above, so the arguments to the Execute method are the questions to consider. As shown in the beginning, I use object to receive, but inside the service

 Public classNextaccountingdateserviceextendsService<nextaccountingdaterequest>{@SuppressWarnings ({"Rawtypes", "unchecked"}) @Override PublicMap Execute (nextaccountingdaterequest request) {//TODO auto-generated Method StubMap result =NewHashMap (); //Find out the current billing date firstString Pdat = Daoutil.getmapper (sysparammapper.class). Selectbyprimarykey (Commondict.pdat). GetValue (); Date currentdate=dateutil.getdatefromstr (Pdat); //Calculate Next DateDate nextdate =dateutil.getnextdate (currentdate); //RecordSysparam record =NewSysparam ();                Record.setvalue (Dateutil.getdatedashformat (nextdate)); //Examplesysparamexample example =Newsysparamexample ();                Example.createcriteria (). Andkeyequalto (Commondict.pdat); //Do updateDaoutil.getmapper (Sysparammapper.class). Updatebyexampleselective (record, example); //Query againPdat = Daoutil.getmapper (sysparammapper.class). Selectbyprimarykey (Commondict.pdat). GetValue (); Result.put ("Pdat", Pdat); returnresult; }}

It must be compiled here, but it needs a strong turn. So in order to solve this problem, we end up using generics

 Public Abstract classService<t> {        PrivateList<interceptor>interceptorlist; @SuppressWarnings ("Rawtypes")     Public AbstractMap Execute (T request);  PublicList<interceptor>getinterceptorlist () {returninterceptorlist; }     Public voidSetinterceptorlist (list<interceptor>interceptorlist) {         This. interceptorlist =interceptorlist; }}

The abstract service class after using generics is the above.

This avoids the immediate unnecessary code that casts in the code, and of course the compiler may also be strong. But at least the code you wrote looks neat.

Springbank Development Log Redesign action call service parameter passing using generics to resolve type conversion problems