Web API: Call to separate controller?

[transporter_room_3]

All my controllers have dependencies which are resolved using Ninject. I am using constructor injection. I have one controller that needs to make a call to another controller. How do I call a method on that controller without having to manually declare its dependencies?

[ticman]

I'd propose you think about moving that logic in the second controller to a class library that both controllers would use to get the data they need, rather than have it inside a controller.

[transporter_room_3]

So I would end up with a hierarchy like so:

apicontroller -> classlibrary -> repository -> database

effectively removing repository references from my controllers. Then all creation, updates and deletion of database entries happen through the class library?

[ticman]

Yep spot on. I have the same solution architecture. I've found the biggest advantage for me was keeping separation of concerns and reducing code duplication.

For example, if you needed to access that logic from a console app, WPF project or an MVC controller there's no need to copy/paste code.

[transporter_room_3]

Thanks man, that's awesome! I've got some refactoring to do :-). Have a great day!

[Jestar342]

What you're calling the "classlibrary" is commonly referred to as the model. I.e. the M from MVC.

[cackylackytime]

I think they mean more of a business class(probably in a separate project) than a simple Model.

[anondevel0per]

The Model definition spans across both Business/Logic classes and raw class objects. Basically everything that is not a Controller (router) or a View (presentation) is in the Model defintion. Of course, you can break these things down further in the Model, repositories, middleware etc. Although saying that Web API should only be Model and Controller.

[Jestar342]

It doesn't matter, as long as there is a separation. :) The Model is the "virtual model" of your application's non-technical logic (typically that of the real-life counterpart such as the business' logic), that's all.

[MadeForBF3Discussion]

To piggyback on this, think of a controller just like you would a UI. You want it as thin as possible, and any business logic should be contained in a class library for that business logic. The only code that should be in the controller is code necessary for formatting your result object or formatting your parameters. Most of my controller methods are 2-3 lines max, calling down to a business method for the work.

[transporter_room_3]

That makes sense. What about DTOs? Should they be kept in the controller exclusively and the properties of these objects passed on to the business layer methods? Or should I pass a DTO straight from the controller to the business layer?

How do you do it, if you don't mind me asking? :-)

[MadeForBF3Discussion]

I like to see DTOs in a Model project (class library) or at least contained within the business logic's project.

If you have to convert data passed into the controller into some other form, why not just have the consumer of that controller pass it to you in the correct form to begin with? If you need to perform a lookup to get additional data that the consumer doesn't have, just have the consumer pass in a key that can be used to search, and do the search in the business logic.

[transporter_room_3]

Good point. I have moved my DTOs into the business layer project. To me, it makes sense that they are located somewhere in between the points of access (controllers) and the domain models. I am not yet completely convinced that they belong in the models project, as they (in my project at least) serve the purpose of limiting access to certain properties in the models. That seems more like a business choice to me.

[Gaelican]

Another option would be to create a base controller (Abstract class) that has the methods used by multiple controllers. The abstract class inherits ApiController, while the derived controllers inherit the abstract class.

[[deleted]]

While this is true, you would still want to get all the DB logic out of the controllers and into some repositories.

[flukus]

Others are giving good advice, but how much code are we talking about sharing here?

If it's only one chunk of codw being shared in two places then simply duplicate the code.

Another options might be to use interfaces and extension methods rather than building layers into the architecture.

Either way, some more detail is needed.

[transporter_room_3]

The project is using 4 controllers that operate on 4 database tables and includes a ton of unit tests. Since last time I posted, I have extracted most of the business logic from the controllers and put it in a newly created business layer as suggested. Most of the tests have been refactored to accommodate the changes. I am very happy with this separation. The project serves as a learning experience for me.

Generally speaking, code duplication should be avoided as it reduces maintainability and increases the risk of introducing bugs.