Could someone please clarify which one to use or what the considerations are for selecting the SelfServicing or Adapter code generation option? I am developing ASP.NET applications and would like to settle on one of these for the DAL/BLL code. Thanks. Btw I think LLBLGen is fantastic!

When to use which template group? Both template groups offer a wide set of functionality, but do that in a different way. This difference makes it important for you to know when to pick which template group for a given project. Below are two short lists which sum up some reasons for choosing each template group and which will help you with the decision which template group to take.

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.

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.

So as you can read, it really depend on what you need to do in your project(multiple database type, webservices,lazy loading ..) You can find all the text in the manual, section: Concepts - Templates and Template groups

For your case I prefere adapter scenario because you can change your database type quickly. It will depend on what you want to do in ASP.NET (read lot of data, forms ...)

Thank you for pointing me to the documentation

I suppose the data scenario under which you would use either is the key factor here. I'm looking at a SQL Server database only , but complex 1:n and m:1 data relationships and the web pages have to load a lot of data and update a lot of controls. Web services will be used too.

Thank you for the rapid response.

Hello,

if you want to use webservices with llblgen pro, you need to use the adapter scenario.

sbense wrote:

Could someone please clarify which one to use or what the considerations are for selecting the SelfServicing or Adapter code generation option? I am developing ASP.NET applications and would like to settle on one of these for the DAL/BLL code. Thanks. Btw I think LLBLGen is fantastic!

I would use adapter scenario in any case. I really don't see any benefit using SelfServicing scenario. Perhaps that's just me.

mihies wrote:

I really don't see any benefit using SelfServicing scenario

How exactly would you use data binding then if you used the adapter style here?

Pretty much the same way you would in the SelfServicing model with the sole exception that you have to explicitly load data. If there is ever a form/ASP.NET event that will require any data to load, you simply catch the event and load the data you need. I also agree with mihies, I stopped using SelfServicing a couple of years ago since in the adapter model you have complete control.

-Seth

I strongly recommend adapter. In fact, I wish LL would depreciate then remove selfservicing all together. Admittedly selfservicing looks nice, especially when you show those 2 lines of code samples for calling up an entity. But when you start using it with complex object graphs, you realize that lazy loading will not work performance wise.

At least in my experience, I think that the adapter vs selfservicing choice unnecessarily confuses new users. Fran, are there any plans to get rid of selfservicing someday? (Or maybe combine the two?)

luciusism wrote:

I strongly recommend adapter. In fact, I wish LL would depreciate then remove selfservicing all together. Admittedly selfservicing looks nice, especially when you show those 2 lines of code samples for calling up an entity. But when you start using it with complex object graphs, you realize that lazy loading will not work performance wise.

At least in my experience, I think that the adapter vs selfservicing choice unnecessarily confuses new users. Fran, are there any plans to get rid of selfservicing someday? (Or maybe combine the two?)

With v2.0 development I've tried to combine the two, as in: make selfservicing a specialization of Adapter.

The thing was however that the architecture wasn't really combinable without creating huge problems with upgrading, there were simply too much breaking changes. So I gave up.

No there are no plans in dropping one or the other, as both have their place and we support both because they appeal to different groups of people so we don't force one onto the other. Similar to that we won't drop VB.NET support.

We will be making more changes which are template group specific in the future (we already did in v2.5 as well with xml / serialization support): if some feature doesn't really make sense on selfservicing (as it's for example used in distributed scenario's) we won't add it to selfservicing and vice versa. In v2.5 we for example added fast serialization to adapter as selfservicing is discouraged in distributed scenarios. We also optimized the Xml serialization a lot and added much more compact XML support to adapter and not to selfservicing as selfservicing isn't really usable in webservices scenarios.

What we will do in v3 is to drop .net 1.x support. But that's about it. If one asks me personally, should selfservicing be dropped, I still would say no, though if I could change one thing about llblgen pro it would be to make selfservicing a specialization of adapter as that's actually the right architecture. The thing is though that we started with selfservicing and adapter was added later on, so refactoring it now is a complete impossible mission.

I always like to use the two hierarchies to explain that agile development isn't all about YAGNI and no design up front: if I would have known adapter would have to be added anyway (We developed (and still do) llblgen pro in a user-scenario oriented approach, so no big design upfront) I would have designed the architecture way differently. Refactoring it now is technically possible but the price is simply too high, simply because it's released software and in that world there are simply way different rules than when you're working on a product that hasn't been released yet.

That's also why I always say that refactoring isn't free, it never is. Don't rely on it to make your software better, it should be great from the start. I'm still pleased with the design of llblgen pro as it is now, but it would have been better if adapter would have been the underlying layer of selfservicing. But as my mother always used to say when I was a kid: "If we would know everything up front, it would make becoming rich a walk in the park".

Dropping features in a released product is a difficult thing. Changing features because of the architecture is almost impossible to get away with. That's what makes software engineering so hard and migration processes of software from v1 to v2 often a difficult task, at least more difficult than the agile movement wants us all to believe. OF course 'agile' simply means 'adaptive to change' but the change is only in adding new features, not CHANGING behavior, at least not on a large scale: people will see there's no upgrade path and will drop it entirely as it doesnt provide them any continuation in the future and rightfully so.

The blog of one of my closest friends, Jeroen vd Bos (http://jvdb.org/blog/ ) is almost entirely spend on this problem: how to migrate software from vX to vX+1, or in general: software maintenance. If we want it or not: in the near future the far most work done in software development is maintenance related. What's more scary... in a couple of years there are more software applications on the world than that there are software engineers to maintain them...

Thanks for the great reply Frans! I know I'm kinda hijacking the thread, but have you ever though about surveying llblgen users to see what they are using?

Just informally looking at the forums, seems a good number of people have moved from self to adapt, not the other way around. I did the same thing. I was seduced by the simplicity of self. I looked at the limitations and it wasn't clear to me that lazy loading meant sql queries for each relationship, and not knowing when it was calling sql (save for debugging). I quickly moved to adapter... not b/c I needed the additional features such as remoting, but b/c I hate the idea that I might "accidentally" create really inefficient code (i.e., forgot prefretch when looping related entities)

I might be completely off the mark here, but wouldn't you want to recommend adapter for all new users? Adapter will get all the new features, it's probably what most people already use, and by having people start with adapter, you prevent them from having to learn two systems once they move away from self. (Like I had to)

Anyways, I'm sure you've given this a lot more thought than I ever have. My 2 main concerns are preventing future people like me from starting w/ self and then realizing half way through development that adapter is the way to go, and maybe by depreciating self LL can spend more time on adapt? (e.g., is LINQ here yet)

P.S. Not to imply that the mistake I made in choosing self was due to poor documentation... rather since LL was my first ORM, I didn't fully appreciate the problems w/ lazy loading.

Thank you all for the feedback. Adapter it is!