Vibrant discussion about CSLA .NET and using the framework to build great business applications.
I'm working on a project that uses CSLA.NET, and while I understand the basics of the framework I rarely touch that part of the code.
We have a number of classes that provide business logic and act as glue between our MVC controllers and business objects. Can these be vanilla classes or should they inherit from one of the CSLA classes? Or perhaps there's a design issue and these methods should be part of a relevant business object?
Sounds like you are writing some ViewModels (i.e. that's the glue).I think there is a CslaViewModelBase class that helps here with binding - worth investigating.
The classes contain no properties, only methods that manipulate data based on parameters and/or make calls to a third party webservice.
Can you show an example?
"We have a number of classes that provide business logic...." sounds like they might be candidates for being in your business layer model.
If you wanted them to be CSLA inherited classes, what would they be? Command objects maybe? What are they actually doing in your user story?
They're indeed more our less our business layer.
I don't specifically want them to be CSLA inherited classes, it's just being done this way right now and I'm wondering if it's necessary.
Our flow is something like this:
Sounds like that's a management / team choice then - do you follow the existing pattern and process or is there a good reason to NOT use the existing pattern.
Your choice - your decision.
If you are using CSLA to create data-centric objects (basically as an ORM) then you are missing out on most of the value of the framework.
CSLA isn't an ORM, it is designed to help you create a business layer that encapsulates all your business logic. So if you allow business logic to "leak" out of the business layer, then you are compromising your overall application architecture - at least as CSLA is designed to work.
Rocky