Is LLBL Gen Pro based on a CRUD Architecture? How does concurrency is garanteed when using the Adapter model?

My worries came after reading the following article from Microsoft (2004) specially their recommendation When CRUD?

http://msdn.microsoft.com/en-us/library/ms978509.aspx#crud%20only%20when%20you%20can%20afford%20it%20rc3a__topic5

I will be having a lot of updates on my web application.

LLBLGen is at it's heart a data access layer, how you implement concurrency control is entirely up to you. There is a section in the documentation about to physically implement it.

The article seems to be arguing the case for a service oriented business layer, with the only specific actions available to the end user. You need to make the decision for yourself about whether this is the approach for you - even if it is, you still need to implement some form of currency control.

Matt

LLBLGen Pro fully supports concurrency, in-memory editing, etc. Many of us use Optimistic Concurrency (Timestamp field) with great success. If you would like an example, please just let me know.

You can go to the database as often as you like, or stay in-memory editing Entities as long as you'd like. You don't need to hit the database every time you edit an entity. You don't need to hit the database every time you delete, either. LLBLGen Pro fully supports in-memory delete using RemovedEntitiesTracker collection.

LLBLGen Pro can be used by your business processes & you can update multiple related entities at once. Entities do not need to exist on their own; they can have relations to all sorts of other Entities.

No need to worry. ; ) LLBLGen Pro does not lock you into any method to add, edit, delete. You can do anything you want.

If you have further apprehensions - Please let us know so we can help you out!

Hope this helps -

Ryan