I am working on an MVC project and want to make use of the BrokenRules to show errors on the view.
Within my objects, I am using the DataAnnotation and in AddBusinessRules() I am calling the base method (base.AddBusinessRules) so it links up the DataAnnotation error with the BrokenRules collection.
One difference I have is that instead of providing the BusinessBase object that has this broken rule, I am creating a DTO (which only has the BusinessBase properties) and returning it to the controller. I want to make sure the controller always goes through the Service layer and does not have access to any of the BusinessBase object's methods.
The DTO that is passed back does have a list similar to BrokenRules collection, but I do not know what I'm suppose to do with the list so that the ModelState gets updated to show the error messages.
- Andy
You are certainly going a different direction than we are with MVC support in CSLA.
CSLA is designed with the idea that the UI (whatever kind of UI that is) will interact with the rich domain object model. So the objects (via CSLA) implement all sorts of features to support UI development - including rich access to the broken rules collection.
If you want to put an abstraction layer between your business layer and the UI, that's probably fine, but it defeats much of the value of CSLA.
CSLA 3.8 has a CslaModelBinder that helps you bind objects in the model, taking care of the otherwise duplicated DataAnnotations invocations.
CSLA 4 will have a more powerful CslaModelBinder, along with a controller base class that exposes protected methods to simplify the creation of at least the common CRUD operations a controller usually contains.
But all that is based on the assumption that the UI is interacting directly with the domain model.
The main reason I was thinking of using the DTO was to force the
controller to go through the Service layer. I would still do the
validation in one place (the BusinessBase object), and then copy the
broken rules to the DTO.
I'll take a look at the CslaModelBinder.
Thank you!
In the CSLA model the data portal is the "service layer". And if you actually do have services, they should be treated as data sources and would be invoked in your DataPortal_XYZ or object factory methods.
This, at least, is the model around which CSLA is designed.
UI -> domain objects -> data portal -> domain objects -> DAL -> database/services/files/etc
In the case of an MVC pattern, the "UI" is composed of Controller and View constructs, both of which have access to the domain objects.
Copyright (c) Marimer LLC