Maintainability of your code is always a big concern when determining where business logic should go. Integrated debugging tools and more powerful IDEs generally make maintaining middle tier code easier than the same code in a stored procedure. Unless there is a real reason otherwise, you should start with business logic in your middle tier/application … Read more
I prefer to put domain logic in the model for a couple of reasons. The model should have no UI code in it and thus be easier to test. Whenever possible, I like to have a fully working (meaning complete test coverage) model before writing any UI code. The controller can trust that the model … Read more
Fist of all: I believe that you are mixing up the MVC pattern and n-tier-based design principles. Using an MVC approach does not mean that you shouldn’t layer your application. It might help if you see MVC more like an extension of the presentation layer. If you put non-presentation code inside the MVC pattern you … Read more
Generally a Spring service is transactional. Things go into a particular service method because they ought to be grouped together in the same transaction. If you want to retrieve an object from the database, twiddle it, and save the new version, the retrieval and save ought to be in the same service method. So your … Read more
Business logic should really be in the model. You should be aiming for fat models, skinny controllers. For example, instead of having: public interface IOrderService{ int CalculateTotal(Order order); } I would rather have: public class Order{ int CalculateTotal(ITaxService service){…} } This assumes that tax is calculate by an external service, and requires your model to … Read more