It seems to me that the controller in Salesfore MVC Architecture has a tight coupling between sObject (Model) and View (VF page). The first line of the VF page captures the coupling through the controller attribute. sObject is basically not really object in classical OO sense, it is a database table.

This is different from other MVC architectures such as struts, in which the controller has coupling between View and Model through RequestProcessor and domain objects. The database is never coupled with view in struts or such MVC patterns.

Am I correct in above observation? If so, is it possible in Salesforce MVC architecture have strong coupling between view and an apex class?

2 Answers 2


Visualforce Pages and Apex classes are tightly coupled.

The standardController attribute of apex:page can be set to the name of an sObject (which is a database table not an OOP-object), in which case it is abstracting the controller logic out for you.

If a standard controller does not make sense for you, it is possible to utilize the controller attribute which should be set equal to the name of an apex class. This and merge fields provide the tight coupling between view and controller you are looking for.

Additionally, you can use the extensions attribute to add additional logic on-top of both a standard or custom controller.


There are actually two modes of operation: dynamic and static. This applies both to Visualforce and Apex Code.

In static mode, tight coupling of the MVC layers prevents administrators from accidentally changing any later that would break the other layers. For example, you can't delete a field that is used in a controller. Also, the packaging system can resolve static references to classes, fields, etc, greatly increasing the chance that deployments will be successful the first time around.

In dynamic mode, loose coupling of the MVC layers allows the view and controller layers to dynamically determine which object and field to use. This has a distinct downside; the looser coupling can allow fields referenced indirectly to be modified or deleted, which can cause pages to fail, and can prevent the packager from correctly determining which fields should be included with the package.

While it is true that there are some features that are necessarily bound statically (standardController is one of them), multiple pages using different standard controllers can all use the same extensions, assuming the extension is capable of dynamically determining which object it should be using (the system has tools to allow this discovery, but the developer has to intentionally code this flexibility into the controller). Combined with custom components, one can still achieve a high level of flexibility and code reuse.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .