My situation is that I am setting up an Application Server for my client program that will access the database. My client program will make requests to this app server which will then query the database.

I've seen some of the custom database drivers and I am wondering if anyone has written something like a Remoting Driver (sorry if my terminology is wrong) that can communicate requests from the client to the App Server, or if anyone has any insight on the best way to do this.

Thanks, Milos

You will need to use .NetRemoting, if your client apps will always be built in .Net. Otherwise use WebServices.

Thanks Walaa for the reply.

Yes my application will be in .Net and will be using .NetRemoting. Let me try to further explain what I'm looking for.

I currently have an application that uses collection classes similar to LLBLGen but am converting this application to use LLBLGen generated collections. Right now there is no middle tier, it hits the database directly. My goal is to introduce a middle tier (application server) with minimal brute force coding changes. My inspiration for this is that it is a huge application with close to 1,000 tables. I would like to be able to cache data on the application server so that I will not have to hit the database for each request, but that is a different topic.

Lets say in my application as it is currently I have a simple call to fill an entity collection.

entityCol.GetMulti(entityFilter);

From what I understand, a DQE generates the query necessary for this call and then hits the database to get data back. Ok no problem.

When I introduce this new application server tier, however, this will be fine on the application server which has to access the database, but different for the client. Now on the client, I have to somehow change this call to bypass the query generation and the data retrieving and turn this into a request to the application server which will actually handle the work described.

What I would like to know if anyone has had this situation before where a driver was coded up to instead of accessing the database actually turn collection fill calls into remoting requests to a middle tier.

What I want to avoid is coding up a series of EntityManager classes to handle custom requests for each collection type, and to have to go through all the code to change wherever I do a "GetMulti" for instance to something custom as well.

I hope this was a bit more informative and helpful than my first question.

mgolubovic wrote:

Thanks Walaa for the reply.

Yes my application will be in .Net and will be using .NetRemoting. Let me try to further explain what I'm looking for.

I currently have an application that uses collection classes similar to LLBLGen but am converting this application to use LLBLGen generated collections. Right now there is no middle tier, it hits the database directly. My goal is to introduce a middle tier (application server) with minimal brute force coding changes. My inspiration for this is that it is a huge application with close to 1,000 tables. I would like to be able to cache data on the application server so that I will not have to hit the database for each request, but that is a different topic.

Lets say in my application as it is currently I have a simple call to fill an entity collection.

entityCol.GetMulti(entityFilter);

From what I understand, a DQE generates the query necessary for this call and then hits the database to get data back. Ok no problem.

When I introduce this new application server tier, however, this will be fine on the application server which has to access the database, but different for the client. Now on the client, I have to somehow change this call to bypass the query generation and the data retrieving and turn this into a request to the application server which will actually handle the work described.

What I would like to know if anyone has had this situation before where a driver was coded up to instead of accessing the database actually turn collection fill calls into remoting requests to a middle tier.

What I want to avoid is coding up a series of EntityManager classes to handle custom requests for each collection type, and to have to go through all the code to change wherever I do a "GetMulti" for instance to something custom as well.

I hope this was a bit more informative and helpful than my first question.

I don't know if this helps, but this is similar to a scenario I've deployed already. Consider this architecture: Multiple client machine running a rich client application with access to retrieve and manipulate business objects (not directly from the DB Server). A Database Server (Runs the Database). An App Server (Runs the remoting services that mediate between the database and the rich clients). The rich clients employ .NET TCP Remoting (Binary) and talk only to the App Server. The App Server retrieves any data / persists any data to the DB Server.

This is all possible using LLBL where: The App Server requests objects from the Database using the Adapter Scenario.

adapter.FetchEntity(Customer);

The App Server passes this object (Customer) to the rich client. The rich client makes changes:

Customer.Addresses.Add(new CustomerAddress("1 Tom Jones rd, etc"));

and passes this object back to the App Server:

remAppBusinessManager.SaveEntity(Customer);

the remoting Application Server then performs validation where necessary and persists the entity to the database.

This way you have a completely segmented approach. You can also do this another way using the Self Servicing objects and custom templates to generate interfaces to your LL objects, and simply use the interfaces on the client. And you can even go a step further and create custom "lightweight" entities that contain only a few methods and can convert from themselves into the heavyweight selfservicing LL Objects, but that's a discussion for another thread I guess.

Kind regards

Thanks RaFaLe for your insight...

It seems you and I had the same idea for the self servicing approach where I would be making a custom template to generate interfaces for the client.

I've started down that path and it seems like it is going to work well.

Thanks again, Milos