Adapter V's self-service?

Posts   
 
    
MarkReed
User
Posts: 7
Joined: 01-Mar-2005
# Posted on: 07-Mar-2005 10:45:37   

I have read the help on adapter and self-service code generation scenarios. As far as I can see they both offer the same functionality although there are obvious differences in the source code requried to achieve each thing. In terms of DAL, and O/R they both do everything I need:

transaction support fetching with PK/UC saving recursively deleting info from DB accessing related entities.

Does this mean that the only difference is the style of the code (one uses the adapter object and one doesn't) or are the other major pros and cons that I have missed?

Are there some things that just can't be done if I use the 2 class method for example?

Are there any good threads on here which discuss the pros/cons of each method that could help me choose the right one?

Thanks in advance

simple_smile

MarkReed
User
Posts: 7
Joined: 01-Mar-2005
# Posted on: 07-Mar-2005 11:03:19   

Just to clarify:

I am aware of the following pros/cons: - adapter does not lazy load, but you can manually load in related entities. - adapter provides better abstraction as entities don't know about persitance. - adapter supports mulit catalog/connection strings in a much more flexible way. - adapter has greater support for inheritance.

Could I assume adapter is a bit more complex to use but provides all of the things self-sevice does, and more besides?

In other words, if I use adapter I may have a bit more work to do but I will not regret it as it is the most flexible of the generation scenarios?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39933
Joined: 17-Aug-2003
# Posted on: 07-Mar-2005 11:51:02   

MarkReed wrote:

I have read the help on adapter and self-service code generation scenarios. As far as I can see they both offer the same functionality although there are obvious differences in the source code requried to achieve each thing. In terms of DAL, and O/R they both do everything I need:

transaction support fetching with PK/UC saving recursively deleting info from DB accessing related entities.

Does this mean that the only difference is the style of the code (one uses the adapter object and one doesn't) or are the other major pros and cons that I have missed?

Selfservicing has the persistence logic implemented as 'behavior' and in adapter it is applied to entities as a service. This is the main difference, which is the core reason why developers choose one over the other.

Are there some things that just can't be done if I use the 2 class method for example?

Reading an entity from oracle and saving it into sqlserver, using the same code for multiple types of databases, that's a bit cumbersome. Also, because the persistence logic is build in and lazy loading is available, you have to avoid calling save or using lazy loading in remoting scenario's.

MarkReed wrote:

Just to clarify: I am aware of the following pros/cons: - adapter does not lazy load, but you can manually load in related entities. - adapter provides better abstraction as entities don't know about persitance. - adapter supports mulit catalog/connection strings in a much more flexible way. - adapter has greater support for inheritance.

Could I assume adapter is a bit more complex to use but provides all of the things self-sevice does, and more besides?

It lacks lazy loading, something which can be of a great help, and using the separate adapter object can be a bit awkward, as you think in terms of 'persistence logic is behavior'. Selfservicing code uses more typed objects, which makes it not that great for extending the classes generated by inheritance, and the code generated is a bit larger than adapter's.

In other words, if I use adapter I may have a bit more work to do but I will not regret it as it is the most flexible of the generation scenarios?

Adapter is definitely way more flexible than selfservicing. If you don't use / need lazy loading and prefetch paths are good enough for you, I'd definitely go for adapter if you don't want to miss the flexibility provided with adapter.

Frans Bouma | Lead developer LLBLGen Pro
MarkReed
User
Posts: 7
Joined: 01-Mar-2005
# Posted on: 07-Mar-2005 12:49:39   

thank you again for your quick and informative reply

simple_smile