Hi,

I've been familiarising myself with LLBLGen on and off and have finally reached the stage where I want to move my test project from a stand-alone PC to a development environment for evaluation.

Environment for the test app is VS2005 & VB + Adapter V2.5 layered as follows:

UI - windows Forms - References BL, DAL, ORMSupportClasses

BL - Manager type classes doing Fetches/Saves/Deletes References DAL, DatabaseSpecific, ORMSupportClasses

DAL - LLBLGen V2.5/Adapter

DB - SQL Server 2005

Deployment will be via Click-Once

Until now the priority was to get to know LLBLGen, so my test app does not use Remoting (remember, the test project is on a stand-alone PC where I think everything's probably running in the same app domain).

I've read many threads on Remoting but before going there I need some help on where the various levels go, so apologies for these basic questions.

Obviously the db will run on its own server, and the WinForm UI is on the client, but where do the other layers (BL, DBGeneric, DBSpecific) go?

Is the BL and DBGeneric layers deployed with the client and DBSpecific with the Server or are there other options?

..and where would Remoting fit into this?

As a newbie to this area I'm grateful for any and all contributions from anyone - make it as basic as you like.

Thanks

(PS. I've also been reading the manual)

Hello, The exact way you do it may vary but here's an example:

Client side : UI : your windows form application DbGeneric : your entities and business objects ORMSupportClasses : useful when working with entities

• your remoting interface .
• a wrapper to be used by your UI to perform remote actions.

Server Side : Database : your sql server db DbSpecific : persistence information DbGeneric : your entities and business objects BL : your business logic and manager classes ORMSupportClasses : useful when working with entities

• your remoting service which answers the client

Hi, Forgive my ignorance here, I'm searching for the simpliest way of using Adapter.

I thought that keeping the BL local to the UI would reduce network access, so What's the rationale for putting it server side?

Also why is DBGeneric also on the server side as well?

• a wrapper to be used by your UI to perform remote actions.

Whats the purpose of the wrapper? Is it needed to wrap calls to the BL when its located server side?

Thanks

I thought that keeping the BL local to the UI would reduce network access, so What's the rationale for putting it server side?

yes it would, but these are the trade offs you need to consider. just the same the more objects a system contains the more complex the model becomes. however this may be necessary to allow for flexibility and to meet the system requirements.

Also why is DBGeneric also on the server side as well?

this is the contract shared between the client and the server. The the simplest setup the server only knows how to talk to the database and return results. it doesn't know how to render the results. The client only knows how to display the results, it doesn't know where/how the server gets the results.

the more logic present in the GUI the more difficult it becomes to reuse objects and automate tests. if your not looking to automate tests this is mute, but it can be a great time saver when maintaining a system. More work up front... but i digress.

in a client/server setup a simple example is displaying a list of records. the work flow would look something like this: 1. user opens form 2. form calls getList proxy in the client library. 3. client proxy makes a remote call to the server proxy. 4. server proxy recieves call and passes request to actual object. 5. actual object creates the collection using an Adapter and Entity Collection. 6. results are passed to the server proxy 7. server proxy sends results to client proxy 8. client proxy sends results to GUI 9. GUI renders the results on screen

as you can see there is more complexity and objects required for this type of process. if designed correctly each object has a single responsiblity which it preforms. then number of objects is higher, but the purpose of each object is less complex.

Jason, This is very very helpful for me.

Quote: Also why is DBGeneric also on the server side as well?

this is the contract shared between the client and the server.

Ok, so DBGeneric on the server.

as you can see there is more complexity and objects required for this type of process. if designed correctly each object has a single responsiblity which it preforms. then number of objects is higher, but the purpose of each object is less complex.

I'm sold on the idea, but need to relate your work flow to my structure. It will help resolve my ignorance with the terminology.

1. form calls getList proxy in the client library.

As the equivalent of getList resides in my BL, is Client Library the same as my BL with its Fetches & Saves? or is the Client Library an Interface to the methods in my BL?

I'll stop here because my other questions are dependent on your answer.

Thanks

DbGeneric goes on both the server and client.

say you have a service which returns a collection of entities.

public interface IService
{
     EntityCollection<FooEntity> GetAllFoo();
}

public class MyService : IService
{
     public EntityCollection<FooEntity> GetAllFoo()
     {
           EntityCollection<FooEntity> listOfFoo = new EntityCollection<FooEntity>();
           new DataAccessAdapter().FetchCollection(listOfFoo, null);
           return listOfFoo;
     }
}

The proxy objects will control access to this service. The details of this I'm not sure of (never worked with remoting). but it would look something like this.

public class ServerProxyService : IService
{
     private IService service;

     public ServerProxyService() : this (new MyService())
     {
     }

     public ServerProxyService(IService service)
     {
           this.service = service;
     }

     public EntityCollection<FooEntity> GetAllFoo()
     {
            //get request from client, then...

            return service.GetAllFoo();
     }
}

public class ClientProxyService : IService
{
     public EntityCollection<FooEntity> GetAllFoo()
     {
            //call server proxy service, and return value;
     }
}

the gui would make a call to ClientProxyService.GetAllFoo(); which intern calls the server proxy. the server proxy call the actual service which returns a list of foo entities.

this could probally be simplified to remove the client proxy object, but this would reduce automated testing coverage.

Ok. Just got back to this after some more reading and a look at the Remoting example on the site.

say you have a service which returns a collection of entities.

I can see the reason for this (equivalent to Service in the Remoting example) and I presume that your ClientProxyService is an interface to the service methods on the server.

*** So what is ServerProxyService or what does it do

I now have a better appreciation of stefcl's response but am still puzzled by 2 things.

Client side : UI : your windows form application DbGeneric : your entities and business objects ORMSupportClasses : useful when working with entities

• your remoting interface .
• a wrapper to be used by your UI to perform remote actions.

Server Side : Database : your sql server db DbSpecific : persistence information DbGeneric : your entities and business objects BL : your business logic and manager classes ORMSupportClasses : useful when working with entities

• your remoting service which answers the client

• a wrapper to be used by your UI to perform remote actions.

Does anyone know what this does or why its necessary?

BL : your business logic and manager classes + your remoting service which answers the client

Is there a reason for not combining these?

Thanks - much appreciated

the serverproxyclass is responsible to accepting the client request and responding to the request. it is a simple lightweight object. The manager object is responsible for loading the collection. it returns the value to the serverproxy which in turn sends the collection to the client.

The actual manger object doesn't know where it's passing the return value to. it is not aware of the proxy.

by having the proxy and the manager inherit the same interface you could just as easily move the manager to the client and remove the need for the proxy.

Is there a reason for not combining these?

Yes. Each object should have a single responsiblity. The manager is responsible for getting the data. The proxy is responsible for directing traffic.

I like the idea of keeping the BL server side, so its a case of firming up on the details of a Server Proxy Class, before I try an implementation.

Any takers for providing a remoting example of what a Server Proxy Class might contain

Thanks

use the remoting example as a starting point. where the example instantiates an adapter and entity collection replace with your manager. the manger will do this work instead.

Jason,

Many thanks for your guidance