How do constructor parameters of a MVC Controller get set?

There's no magic unless you consider dependency injection magic. If you dig around in that app's start-up/bootstrap code, you'll almost certainly find an IoC container. Look in Global.asax.cs and follow the paths from your application start event handler. You'll find component/service registration in there somewhere. Sometimes it's right in the Global.asax, sometimes it's stored in App_Start, sometimes it's in the root, and sometimes it's elsewhere. It's there, though.

The latest versions of ASP.NET ship with built-in dependency injection. The latest versions of MVC put it to use.

If you're using an older framework, there are many third-party containers. A few examples:

• Unity
• Autofac (my current favorite)
• Ninject

The principle is simple. You register some concrete type as the active representation of a contract. (The contract is usually an interface, but could also be a concrete type.) Then in code, you always refer to things as contracts. The container gives you the registered type, but you don't have to think about the details. This makes it easy to swap out implementations in one and only one place. Which in turn makes it easy to do things like test pieces of code using predictable mock objects versus using unpredictable, complex objects. Complex objects make it difficult to understand what you're really testing.

In addition to registering types as contracts, IoC containers also do fancy things like automatically inject types into managed components. That's what you're seeing in your example. The container is managing your controllers, so it knows to provide an EmployeeController to your AdvancedSearchController. Who knows? Maybe it injected some other type into the EmployeeController before it passed it on. (You didn't ask, but I'm not crazy about passing controllers around. If you have any say in the matter, ditch it. Replace it with some non-controller that does the needed work. Controllers should only knit models to views. )

Some containers also let you decide the lifetime of your registered types -- maybe they're instantiated each time they're used, maybe an object sticks around for the duration of a web request (slick for managing a unit-of-work in a web service), or maybe there's only ever just one.