Guys,

    We are at initial stages of our project. We chose LLBLgen and started working in Selfservicing code. After two months, now we have issues in multiple connections to datbases using Selfservicing code. Now, if we move to Adapter , will be loose any feature of selfservicing.

1. Which one is better , Selfservicing or Adapter?? Ours is a big project which accesses multiple servers and databases.
2. If u use Adapter , will i loose anything? i mean some selfservicing features which i may not get in Adapter classes.

Can you guys list out points in terms of design pespective , which one to use .

like,

Adapter - Multiple Databases - ???

Selfservicing

• ???

So, i need to decide what code generation i should go for .

Some thinsg abt our project

• big team
• big project
• multiple datbases

I know u r answer may be use Adapter. But just want to make sure i have points to convince ppl why Adapter.

Is it just because i want to connect to multiple datbase, i shoudl use Adapter.??

Just to add to this,

please put some links which can give me exact idea which one to use in which business scenario.

Thanks

Here is a basic comparisson for Adapter and SelfServicing.

In your situation - Adapter, without question. The multiple servers, multiple databases item is enough to settle the question.

The only thing you really lose is lazy-loading, but this can be worked around with Pre-Fetch paths, and I've never missed it.

Matt

When to use SelfServicing

* When the project targets a single database type.

      I am fine with this.

* When you are not using a distributed scenario like remoting or webservices.

      So, does thsi mean , if we are having methods exposed as webservices , we should not use selfservicing.

* When you need navigation through your object model in a databinding scenario and you want to load the data using lazy loading.

fine with this as well.

* When you don't need to extend the framework.

   what do we mean by this?? Could not get exactly what we mean by this.

* When you like to have the persistence logic into the entity classes.

     what do we mean by persistence logic. can you help me out understanding this.

If i use Adapter , i will not have any persistence logic or what?? Please explain.

* When you do not require fine grained database access control, like targeting per call another database.

    Fine with this point as well.

When to use Adapter

* When the project targets multiple database types or would be able to do that in the future.

 Fine with this.

* When you are using a distributed scenario like remoting or webservices.

   why is that only adapter should be used when we have 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.

    fine with this as well.

* When you need to extend the framework with derived classes.

 why does selfservicing doesnt support this. Could not get this point. can anybody explain.

* When you like to see persistence logic as a 'service', which is offered by an external object (broker, adapter).

    can anybody please throw some light on persistence logic scenario and why adapter.

* When you require fine grained database access control.

   I understood thsi.

* When you want to convert Entities to XML and back and performance and XML size are important.

    cant we do it with selfservicing. why adapter??

Can i get some lines explaining thsi so that i can decide and convince my management which wayto go. I understand multiple datbase is enough for a reason, but what drwbacks it brinsg with it when i use adapter. i am interested in that as well.

Sandumone1 wrote:

When to use SelfServicing

* When the project targets a single database type.

      I am fine with this.

* When you are not using a distributed scenario like remoting or webservices.

      So, does thsi mean , if we are having methods exposed as webservices , we should not use selfservicing.

Yes, you should use Adapter.

* When you need navigation through your object model in a databinding scenario and you want to load the data using lazy loading.

fine with this as well.

* When you don't need to extend the framework.
   what do we mean by this?? Could not get exactly what we mean by this.

Adapter makes it easier to extend/modify the templates and generated code to add extra functionality

* When you like to have the persistence logic into the entity classes.

     what do we mean by persistence logic. can you help me out understanding this.

If i use Adapter , i will not have any persistence logic or what?? Please explain. With Adapter, your persistence logic is seperated from your entities, and is in a seperate assembly. This seperation of concerns [url]http://en.wikipedia.org/wiki/Separation_of_concerns[/url] is generally considered a good thing in software development

* When you do not require fine grained database access control, like targeting per call another database.

    Fine with this point as well.

When to use Adapter

* When the project targets multiple database types or would be able to do that in the future.

 Fine with this.

* When you are using a distributed scenario like remoting or webservices.
   why is that only adapter should be used when we have webservices.

As described above, because the persistence logic is seperate from the entity classes it makes it much easier to serialise the entities as they do not contain database behaviour, they are really just containers of data

* 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.

    fine with this as well.

* When you need to extend the framework with derived classes.

 why does selfservicing doesnt support this. Could not get this point. can anybody explain.

* When you like to see persistence logic as a 'service', which is offered by an external object (broker, adapter).

    can anybody please throw some light on persistence logic scenario and why adapter.

As above,persistence logic is seperate from the entity classes. * When you require fine grained database access control.

   I understood thsi.

* When you want to convert Entities to XML and back and performance and XML size are important.

    cant we do it with selfservicing. why adapter??

For the same reason as with webservice, Adapter entites are just containers of data with no persistence behavior, so much easier to serialize

Can i get some lines explaining thsi so that i can decide and convince my management which wayto go. I understand multiple datbase is enough for a reason, but what drwbacks it brinsg with it when i use adapter. i am interested in that as well.

There are NO significant draw backs to using Adapter. The only significantly different bit of functionality is the lack of lazy-loading, but in a large multi user, multi database environment you are much better off handling this your self with Pre-Fetch paths.

To summarize - SelfServicing is only really suitable for small, single tier, single database projects. I've been building apps of all sizes with LLBLGen for over 5 years, have always used Adapter, and have never found myself thinking "I wish I'd used SelfServicing"...

Matt