I have a solution using DataAccess ORM and a WCF plain service.
My Presentation Layer is Windows Forms and I use a Grid Control. I have configured WCF to return BindingLists and I set the grids datasource to that binding list.
I change several rows in the grid. I add new rows to the grid and I delete a row in that grid.
--
I have a save button and when I click on that button I call the Update method on the WCF. It seems to only handle modified rows and not added or deleted rows. I would have preferred if it had worked in the same way as ADO.NET works. IE there you have a datatable where some rows have the rowstate modifed, some are added and some are deleted. One call to the DataProvider does the neccessary insert, update and delete statements.
As is now I have to handle inserts and deletes separately. and if the user exits the form without saving I would like to rollback any Changes made since the last save (or when the form was opened).
It would be nice if the dto classes could implement some type of rowstate.
--
I need to implement a Business Logic layer in my app as well.
For example I have two tables with a foreign key constraint between them. If the user tries to delete a row on the parent table and there are rows in the Child table rererencing that parent I want to check with my security system if the user is authorized to delete the Child rows as well and if so delete the Child rows and then the parent row or else throw an exception.
I want certain forms that will work with several tables and when I press the save button in that form several binding lists should be sent down to the business logic layer. There I want to start a transaction. Check data against some rules and then save the data to the database taking into consideration any Foreign Key contstraints.
--
I tried to delete a row in the grid and when I tried to save that to the database it threw an exception because of a foreign key constraint.
That row had Children. I tought that it could be nice if the dto classes could have a property for this. I could then in the Business Logic layer method loop through the Collection and check for this. In the grid Control I could then signal this to the user by changing the background color of the row (meaning this row can't be deleted).
--
When addin a domain model to my Data Access layer I would like to have the option to update a single table if it has changed.
--
In the service wizard I would like to have the following options:
- Only updating the crud methods for a single table
- Selecting several tables of my choosing and create joint crud methods for these tables (IE one BLL method that updates all tables withing one transaction).
- When updating the service for an existing method that already has an Business Logic Layer method the existing code within that method must be preserved.
--
My biggest need for now is to implement a Business Logic Layer and I've looked at the code that was generated by the service wizard to see if I could modify the WCF service to route all calls through a Business Logic Layer and it wasn't that easy to understand.
So my questions are:
Can you implement this into OpenAccess ORM?
If so what timeframe are we talking about?
If not can you send an example on how that code should be modified to implement a Business Logic Layer between the WCF service and the Data Access layer?
1 Answer, 1 is accepted
Thank you for your feature suggestions.
Here is our feedback on them:
Scenario 1: Handle Inserts, deletes and updates in single service method and in single transaction.
I have added a new feature request in out Public Feedback Portal:
http://feedback.telerik.com/Project/114/Feedback/Details/46953-plain-wcf-services-add-service-method-that-can-handle-inserts-updates-and-delet
Scenario 2: Business rules that validate security permissions and referential integrity.
How do you imagine this implemented using generic code generation? If you say it is business logic I do not believe any wizard will be able to capture easily the specific rules and make any sensible decisions based on that. If Scenario 1 gets implemented you should be able to add the required business rules in the service/repository implementation itself. Also OpenAccess will prevent you to delete any entities that will violate the referential integrity of your data by throwing a relevant exception.
Scenario 3: Know when parent entities have children and cannot be deleted.
You can already implement this following the guidance in this article. You can either check if any children are present in the collection property or if you don't want to transfer additional data over the network you can add a new boolean property (HasChildren or CanBeDeleted) that is calculated in the Assembler method.
Scenario 4: Apply changes in single table to the already generated by Add OpenAccess Service wizard code
There is already such feature request and you can vote for it to show your support:
http://feedback.telerik.com/Project/114/Feedback/Details/43471-enable-incremental-updates-for-the-generated-by-add-openaccess-service-wizard-cod
Scenario 5: Smart updating of CRUD methods and special treatment of custom methods.
I believe this can be merged with Scenario 4. In order to avoid your customizations to be overwritten you should always use partial classes to extend the generated code. Finding which generated methods have been modified parsing the source code is extremely hard and I doubt that we will ever implement such algorithm.
My advice how to proceed with the current feature of the wizard will be to use it as starting point of building the service layer once and then manually extending and updating/maintaining the generated code to match your requirements.
I cannot give you any timeframe for implementation of the features that you have requested.
My suggestion how to implement the business layer will be to put it on top of the generated repositories layer. The business layer should control the translation from Entity to EntityDto types and back, do the validation of incoming data and control the size of the graph of objects that is transferred between the client and the server. Introduction of the business layer should lead to modifications to the Service layer only.
Viktor Zhivkov
the Telerik team