Hi all,
My situation is as follows:
I have a service that receives a list of some entity in order to do some kind of operation on each of the entities in the list:
1. The operation is the same for each of the entities (updates one of the fields)
2. There is a logical test to perform on each entity in order to know if the operation can be made or not
3. The response of the service is the original list of entities, where for each of the entities has a flag that states if it was updated or not (in case it didn't, there is a reason)
I'm architecting my server side in a layered architecture :
- Service layer which also acts as Business Workflow
- Business Entities (Custom business entities and Typed Datasets)
- Business Components
- Data Access Logic Components
(quite similar to what microsoft recommends)
So, the problem I'm facing is:
My Business Component layer is designed to handle a single entity (Business entity) at a time, so if I use the current design, I'll need to perform a lot of I/O operations with the DB.
My other, not so prefered option, is to add to the both layers (Business Component and Data Access) methods that can handle bulk of entities, in a way that the DAL takes the list of entities, ships it to the DB and lets the DB do the logic (using stored procedures probably).
Any thought on the subject
Thanks,
Ido.
Architecting BLL, DAL and DB for bulk entity updates
Joel Pobar
Another approach would be to use transaction scripts: collect all SQL queries/SP invocations for individual entity operations in one larger query string and submit this in one roundtrip to the database.
If each operation on an entity requires additional interaction with the database, for example to retrieve data that is required for validation or to augment the originally submitted data, the transaction script approach is likely to be harder to optimise than a BLL/DAL that already provide batch support: rather than one query that fetches all required data for the whole batch you tend to end up with one additional query for each batch item.
Regards,
Gerke.
diluted_water
AlexU
What's the business context all these "entities" have arriving at the server Are they tied together (i.e. if one update fails should they all fail ) or just happen to be sent together
What's the usage pattern for the service - do you have steady state you cannot handle or do you have peaks Is it acceptable to defer the processing (e.g. serialize the request into a persistent queue and deal with it later)
By the way why if you have services - it is probably better to separate your service layer (edge of the service) and the orchestration (business workflow) into two layers
Also the service interface you describe sounds CRUDdy (even if you get bulks) which is usually not a good sign for service interfaces.
Arnon
PS
it would probably be better to wait for more details - but here is one option (what the heck ) you can make your DAL components transaction aware and then open a transaction scope at the business workflow layer (probably another reason to separate it from the service interface)
HTH,
Arnon
logogamer
Hi Arnon,
Regarding you questions:
As for the business context - The entities are not tied together, they each stand on it own (so to speak). The reason I wanted this service to handle a bulk of entities, was to match the business requirement - the user needs to apply an operation on a bunch of items he has, where the operation is the same (changes the status of the item to a specific status) and the items are of the same type (you can look at it as barcoding items into the inventory - a methodic operation on a set of items).
Since I know that each operation on it's own might take a while (UI->Service->BL->DB->BL->Service->UI) and the user should not have to wait between items, I decided to design it as a bulk message to the service (that's the only reason why I want to send them together).
As for the usage - this operation is not rare (once every couple of days), but it is quite constant in it quantity (usually about 30-50 items per operation). Deferring the operation is possible, but I would require of me to change the way my UI works (adding notifications) and I don't have the required time and man-power for it right now (but I see where you're going with that idea).
As for the service layer - I know I should separate it and I have every intention of doing so ... one day.
As for the service interface - This specific service is not CRUDy, as you can see from my first paragraph (I'm trying to prevent from using general "update" methods, by applying service methods for each of the functional business requirements). For example, the above mentioned business requirements uses a CRUDy DAL method, which I already created for a different service method (so I have a couple of "update" service methods, but each of them is responsible for a specific update with a specific set of logic).
As for the transaction - right now, my transaction scope is the service, not the DAL (everything that happens in the service method is considered a transaction, so it's quite possible to perform multiple DAL methods in the same transaction). For this specific bulk operation, I'm considering designing this transaction as separate for each entity, because as I mentioned, they are not tight together (this of course depends on the decision where to place the logic and the bulk operation - inside or outside the DB).
I'd appreciate any ideas on the subject.
Thanks,
Ido.
Nyidalur
Hi,
In a B2B solution that makes a lot of since, but the question is how to act in a P2B solution where the P works in a synchronized manner (performs an actions and want to know if it worked or not).
Ido.