Data Passing Data Structures in Clean Arch

Data Passing Data Structures in Clean Arch

Following are Data Structures used to pass data between different layers of onion architecture.

In Case of Queries

For Fetching Data

View ç Controller ç AS ç Data Access Class ç EF Repository

View  ç Controller  (ViewModel)

ViewModel is View Oriented Data Structure for displaying Data on the View. These Data Structures are defined inside the Presentation Project. In the Controller we can add the View Specific Data inside the ViewModel. We can set the View specific Flags those make contain UI elements visible or invisible, enabled or disabled. At this point we can change the Response object to change the HTML generated in response. If this UI orientation is complex and cause long code, we can put this UI logic to separate class (presenter) and call this class in the controller. Presenter beautify the Data Structure in the Orientation needed by the UI. Returned UI Oriented ViewModel is send to UI for Rendering. UI is kept dump. No Logic there. No need to test the UI. Add the UI related flags and specifications. Add UI related strings to the Data need by UI. Like Currently Names, Date formats. Units of measure. If this logic is complex it couldbe passed to the presenter.

Controller   ç Application Service/Query  ( ResponseModel or ResultModel)

Result Model is fit to purpose Clean POCO Data Structure having only the Data Elements need by the Use Case. These Data Structures are defined in the App. Service Project. Controller should never know about the Entity/ Aggregate/ ValueObject because along with the Data they also contain Domain Behaviors that could be leaked to the Controllers and Views. Even in the case of CRUD and Anemic Domain Model (Domain object are just bags of property getters and setters having no logic.), we need specialized Data Structures inside the App. Service Project. Automapper can beused to simplify the Data mapping code. Add remove unnecessary data items no needed by View.

Application Service/Query ç Data Access Class (Entity/ Aggregate/ ValueObject)

Data and Behavior Rich one or more Domain Objects are returned. They should be not returned to the View or Controller as it is. These are half cooked results or we can say this is Raw Data we still need to convert it to presentable Data. We need to make the Fit to Purpose for Use Case. We can add new fields in returned Data Structures. We can filter unnecessary Data that is NOT required by use case. This makes querying really fast. Automapper can be used to simplify the mapping code.

In Case of Commands

Flow While Executing Business Logic

Controller è AS è Factories/Domain Services/Entities/VO/Aggregates Roots/ Domain Events

Flow While Saving Data

View è Controller è AS è  Data Access Class è EF Repository

View è Controller (Web Request Object having all Request Data)

Controller   è Application Service/Command ( RequestModel)

Request Model is fit to purpose Clean POCO Data Structure having only the Data Elements need by the Use Case. These Data Structures are defined in the App. Service Project. We take the Data from the WebRequestObject and fill the RequestModel data structure and pass to the Application Service.

Application Service/Command è Repository (Entity/ Aggregate/ ValueObject)

Repository only talks and operates in the language of Domain Objects. It knew nothing about the other data structures in the View and App. Service Layer. We need to fetch data out of RequestModel and make the Domain Objects. During this Domain Objects preparation we may need to fetch data from the Database.