Hi,

I understand that

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.

these are the thinsg we should take care while using tthe adapter code generation. But, we have a framework which is already built on selfservicing and we dont want to change to adapter now.

Can we customize or write some methods in the framework level to include these fetaures in selfservicing code.

what i eamn is ,

Can somebody explain , if i can have multiple datbase support. we are using only sql server databse, but multiple on per call basis.

we have methods exposed as webservices.can we do something in selfservicng code to make this scenario work.

In similar way, if somebody can tell us how can we customize the selfservicng code to add up these above mentioned features.

NB : My manger doesnt want to shift to adapter now as our framework is in selfservicing code generated mode.

Hi Sandumone1 -

I would highly advise against trying to arm-twist Self-Servicing into performing Adapter-type capacities. This is exactly what Adapter was built for.

As you know - Self-Servicing Entities have direct access to the database. Your UI developers will be able to create/read/edit/delete anything directly in the database - without going through your Business Layer, and without you knowing.

Your Business Layer can be very thin to begin with. You can start off with just methods to do your Fetches, and simply build UnitsOfWork for your Save/Deletes. But if you don't prepare for it now - you won't be able to take control of your database calls later.

Let's face it - Self-Servicing is extremely easy to work with your data. Adapter really isn't any more difficult. It just requires one more line of code to do the database call. Adapter.Save(...) Adapter.Fetch(....)

Since I switched from Self-Servicing to Adapter, I haven't looked back. Many people don't realize, just as I hadn't, how many lazy-loads you are actually doing in Self-Servicing. It is probably more than one might think. These lazy opening/closing connections caused my application to load screens slow. Now with Adapter & prefetching - all the fetches happen up-front & I know when the database is getting hit.

If you need help on your helper/framework methods - please do let me know! We've switched all of our helper methods from IEntity to IEntityCore, which supports both Self-Servicing & Adapter.

The decision is truly up to you & your team. Perhaps you can work with the Solutions Design Team to find some way to hack / force Self-Servicing into a different database connection. However, based on your posts the past few days - Adapter sounds like the right move. Don't fight it if you don't have to.

Hope this helps -

Ryan

Pretty much what Ryan said - Adapter and SelfServicing have different functionalities exactly to suit different scenarios.

We advised you on a previous thread that Adapter was better suited for your purposes. http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=16817

Trying to force SelfServicing to behave like Adapter is a very bad idea - I can absolutley guarantee that it will be less work now and less hassle in the future to make the switch to Adapter now.

Matt