Hi,

we are evaluating LLBLGen pro. i understand that adapter and se3lfservicing handle persisttence logic in differnet ways.

I have a query. where eactly is this persistence logic stored in LLBLGen. Does Adapter and Selfservicing have different approcahes.

When handling concurrency the values are checked from memory or what??

If the persistence Logic is stored in memory, what mesures or features are thereb which can avoid overflow .

Please help me out.

These are questions raised by management team and i have to answer these properly to convince LLBLGen use in the project .

I need a in depth info to talk to management.

Hi Sam,

I'll try to answer your questions. They are mainly explained in docs, so I will post some links.

Sandumone1 wrote:

we are evaluating LLBLGen pro. i understand that adapter and se3lfservicing handle persistence logic in differnet ways.

Please take a look at Stateless persistence.

Sandumone1 wrote:

I have a query. where eactly is this persistence logic stored in LLBLGen. Does Adapter and Selfservicing have different approcahes.

These are the differences between both.

Sandumone1 wrote:

When handling concurrency the values are checked from memory or what??

Yes, LLBLGen Pro have concurrency control support, in such a way that you can decide how to implement concurrency control in your application. Take a look at docs.

Sandumone1 wrote:

If the persistence Logic is stored in memory, what mesures or features are thereb which can avoid overflow .

See my first link.

Sandumone1 wrote:

These are questions raised by management team and i have to answer these properly to convince LLBLGen use in the project .

Have you already seen this? (Convince your manager) http://llblgen.com/pages/convince.aspx

Sandumone1 wrote:

I need a in depth info to talk to management.

Let us know if you need further info.

Hope helpful

Thanks a lot. we may need morehelpfrom you to promote this tool.

Thanks

Sandumone1 wrote:

Thanks a lot. we may need morehelpfrom you to promote this tool.

Thanks

Be our guest

Hi,

 I wnet through the documents and understood the persisitence logic on entity level for selfservicing and Dataaccessadapters for adapter level generated code.

But, as you would have seen a lot and analysed. My doubt here is ifmy manager asks which way to go, I am not able to reach a exact answer.

Can you throw some light on the points which will help me decide which way to sue for code generation for our project.

Ours is a big project and we are expecting a team of 50 developers working for a span of 3 to 4 years . So, its a large scale project.

Please suggest which way to go and if you suggest one , can you give soem reasoning which helps me to overide one over other.

Thanks sam

When to use Adapter

• When the project targets multiple database types or would be able to do that in the future.
• When you are using a distributed scenario like remoting or webservices.
• When you don't need lazy loading scenarios in relation traversals. You can still navigate relations but you have to fetch the data up-front.
• When you need to extend the framework with derived classes.
• When you like to see persistence logic as a 'service', which is offered by an external object (broker, adapter).
• When you require fine grained database access control.
• When you want to convert Entities to XML and back and performance and XML size are important.

When to use SelfServicing

• When the project targets a single database type.
• When you are not using a distributed scenario like remoting or webservices.
• When you need navigation through your object model in a databinding scenario and you want to load the data using lazy loading.
• When you don't need to extend the framework.
• When you like to have the persistence logic into the entity classes.
• When you do not require fine grained database access control, like targeting per call another database.

And, if you are not sure, go for Adapter, it will give more more flexibility if your project grows up.