bruno-brant
commented
5 years ago It's my belief that Liquid is designed to expose API's, so I agree with you that we should inherit from ControllerBase.
In any case, I'd like to pull some insight from @GustavoDenisAva if this was done by design and maybe discuss if there was a desire to enhance Liquid to also serve HTML. If the latter is true, I still want to really double check the proposed architecture, and maybe have two flavors of controllers (just like ASP.NET basically does).
ASP.NET Core provides two abstract classes for your controllers to inherit from. Those are Controller and ControllerBase. The former brings support to Views, while the latter doesn't, keeping only the core stuff. It's important to note that Controller inherits from ControllerBase.
Until now, LightController inherits from Controller:
https://github.com/Avanade/Liquid-Application-Framework/blob/d625dff6d3af90fc9aba210f8898564b7b4f02c7/src/Liquid.Activation/Controller/LightController.cs#L18
Looking at the code of Liquid, we can see that it's was made to be API driven as it uses stuff like swagger and api versioning:
https://github.com/Avanade/Liquid-Application-Framework/blob/d625dff6d3af90fc9aba210f8898564b7b4f02c7/src/Liquid.Middleware/UseBase.cs#L21-L82
Which leads me to wonder if we really need to carry over those view dependencies.
One could argue that, some day in the future, we could use Liquid to return HTML views, for example. But would it go against the framework principles and its intended use? Should LightController inherit from Controller or ControllerBase?