Your question is very interesting and there are several possible solutions. The choice which one to implement is up to you and largely depends on the scenario you are facing.
Here are my suggestions:
- Create a stored procedure that loads all the data from the Employees data table and calculates the number of employees each manager has. Map the result using out Stored Procedure Editor to a complex type and use the result as read-only view of the employees data. Use the normal generated persistent class for create, update and delete scenarios
You hit the "complex" aggregate query only when you need the employees count and use the normal data context features to all operations that don't require the calculated column. This can save you some performance issues.
You need to maintain two almost identical Employee types and make sure you are using the proper one in each case. This increases code complexity.
- Create a view in the database that contains the additional calculated column and map it in your domain context instead of the Employees data table. OpenAccess will handle all CRUD operations.
Code complexity is very low because you are using standard OpenAccess functionality. You have very good chance to utilize OpenAccess cache when querying the view and it will make up for any performance lost due the view.
The view will calculate the number of manager's employees even it is not required in the particular use case.
- Use standard persistent types generated by OpenAccess and create a new scalar stored procedure that calculates the number of manager's employees on demand. Map the stored procedure using the Stored Procedure Editor. Call the data context method mapped to the new procedure each time you need the additional data.
Pros: Suitable if the number of employees is required rarely because calculation is done on demand.
Cons: If you need to show a grid full of employees and you are required to show the employees numbers this approach get very inefficient because it will issue a query to the database for each row.
You can find more information how to use our Stored Procedure Editor
and Complex Types in this video
personal preference will be Option 2
because it doesn't introduce any more complexity in the code and the performance cost is fairly low. But your choice depends on the scenario and the business requirements that are present to you.
If you need any further assistance don't hesitate to contact us.
the Telerik team