Business Logic – Using the Term in Non-Business Applications

That sounds like an eminently sensible decision to me. MVC is a presentation pattern, therefore business logic and persistence operations have no place in the UI layer of the application.

Ideally an MVC model is just the data you are presenting to be rendered by the view. This is not at all necessarily the same as an equivalent domain entity - for instance, the model may need to be tagged with UI validation attributes, may contain values for multiple selection, or may contain data transformed for display such as dates, currency values. or language translations. Because of this, it is sensible to make the M in MVC distinct from your business entities, and map from entities to models in your controller logic. A controller action should not really need to do anything more complicated than make calls to the underlying business logic layer and marshal the data returned into models for render.

You cited

Extension methods enable you to add methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type.

and that is when you should use them almost exclusively - where you have a case where it would strongly make sense to extend a type by that method, but you cannot do this, neither by creating a new derived type, nor by recompiling, nor by any other means modifying the original type.

The typical scenario for this is: the type is sealed, and it is either not under your control - maybe a 3rd party library - or you want to avoid adding a method which requires an additional dependency which must not be added to the assembly where the type is defined.

So the first thing to check here is if these constraints apply, and if not, the favored place for putting an additional method should be the class itself. If the the code cannot be changed, but the class is not sealed, one might consider to use subclassing instead of an extension method. In this situation, I would prefer extension methods over subclassing unless access to protected members is needed. There is actually no benefit in the use of subclassing in this situation, neither in testability nor code organisation.

About testability: extension methods are in no way easier or harder to unit test than any other static or non-static method. Testability or TDD becomes only a concern when other code which relies on such a method needs to be tested in isolation. So if you run into a situation where you need to "mock out" the extension method itself, it is time to refactor the method into an utility class which can be replaced more easily by a mock for testing purposes.

So usage of extension methods is fine, if you

• have a method which fits clearly (!) to the area of responsibility of the type you want to extend

• cannot modify the type itself easily

• cannot or do not want to use inheritance

• don't have the requirement for mocking the function in code which relies on it.

Note there is actually no reason why you cannot start with an extension method, and when you notice you run into its restrictions, refactor the code. Thus, don't overthink this. Note also this has not much to do with the code being business logic or UI code or infrastructure code - when a program is large enough, each of these "layers" can consist of different sublayers and components, which can cause a situation where a "cross-border" type extension is required.