Question about complex application controller design

Hello,

while designing my first MVC application with Yii, I came across the following question:

The application will be accessed over multiple interfaces, standard (HTML) web interface, AJAX for JavaScript based GUIs, webservices like SOAP/REST for communication with other systems and possibly interaction with CLI scripts. Also users/actors will be authenticated with multiple Identity classes.

I’d like to keep the Controllers generic so it stays DRY and the call names and action verbs stay the same. But this seems to conflict with the design suggested by all sample code I saw - Controllers are not generic, i.e. they assume a data input method and render certain views. So I would have to write one for each input method * number of models (or variations thereof, lots of ugly switch cases in the controller or sub classes inheriting from a common controller class), which is barely feasible.

Is there any elegant way to abstract the input/output methods and formats away from the controller, translating those to generic controller actions in a pre-processor maybe? Or do you have another approach for this scenario?

Thanks in advance.

I’m developing something similar(or I think so). I have controllers that serve SOAP/REST functionality, and controllers that server webpages. In my “/controllers” folder is where my “normal” controllers are, they provide web interface to the users. I have “/controllers/services/” folder where I have special CWebserviceController(my own base class) classes which have custom validation as provide SOAP/REST. So in my business classes I alway use Yii::app()->user although they authenticate differentlu.

I understand, but that means you wrote different controllers that manipulate the same model just to deal with different input methods. This is ok if you don’t have too many models and input methods, because the amount of controllers you have to write is m * n.

I think this can be solved with a second controller layer, one controller for each interface type, that translates the requests to the normal, model specific (but otherwise generic) controllers. Then you only have to write m + n controllers. Handling views gets a bit tricky then but could probably be done.

More input welcome.