First and foremost, forgive the ignorance that will be revealed should you choose to read on. I've been using LLBLGen with Self Servicing for about a year now. I've got the oppurtunity to start fresh and refactor my application to make it more robust. I've ordered Ingo's book on remoting as this is where most of my ignorance lies. What I really need help getting my head around is some fundamental stuff.

I want to create a server application that will use LLBLGen for the Logic and Persistence Layers. So, I use the adapter template and generate my persistence layer. Specifically, I have the two generated projects com.mycompany.myapp.persistence and com.mycompany.myapp.persistenceDBSpecific. For some entities, I need additional properties, methods, etc... So, I create a new class library, com.mycompany.myapp.businesslayer. In here, I have two namespaces; businessobjects and adapters. In businessobjects, I have various classes that inherit their corresponding entity class (i.e. User inherits UserEntity) In adapters, I have classes that inherit from DataAccessAdapter (i.e. UserAdapter inherits DataAccessAdapter). I do this so I can intercept events such as OnFetchEntityComplete.

So now, I have the first iteration of my business and persistence layer working (working quite well actually). At this point, I am only testing with a console app that references the dll's. But the time has come to start talking about the client. I know I want to use remoting. I know that if I want to use remoting I am supposed to use the Adapter templates... which I am. I also know that based on almost everything I read, I should use Interfaces to "build the contract" between the client and server application. The term factory keeps popping up as well.

Here's where I start getting really lost.... what's next?

Where do Interfaces come into play? Specifically, if I have an OrderIntity class that I want a windows form application to be able to interact with by way of remoting do I need to create an IOrderEntity interface?

Can anyone draw me a clearer picture or if you have a similar scenario, let me know how you are doing this?

The interface is about the SERVICE interface. So the client knows the type of the service (e.g. 'IService') and the service implements that same interface so a client is able to use it.

The interface isn't about entities, so it's more a 'service' contract than a 'data contract'. The client creates a service proxy instance and uses that object via the interface (e.g. IService). the service also might implement another interface, IService2, which is used by other clients, though that's not the concern of the first client. This way you can version interfaces on your service.

As you decided to use remoting, be aware that 'remoting' is just a choice of infrastructure to implement a solution to the demand to have a disconnected service oriented application. Is that the main goal of your application? Or are you just looking at remoting to offload stuff to the server ? Because if there's no need for service oriented architecture, why not use a thick client instead? (you might have very well defined reasons for the service, so I'd like to learn abit more about them before going further )

As usual, thanks for the quick reply.

I guess I am trying to design this as a client - server app because I feel like I am supposed to. Essentially, I have an application that is becoming the "catch-all" for any functionality needed by my company that our EBS system doesn't meet. Its currently released and being used here and there. In its current state, I have a dll that consists of the genereated peresitence framework (self servicing), a dll where some custom validator classes live (for business logic) and a win forms exe.

Right now, I have about 50 users and two different modules in the application. One module allows users to view and modify Return Material Authorization requests before they are submitted to SAP. The back-end for this module is an existing java based server application. So, I talk to it using web services that are exposed in Apache.

The second module is still under development. Essentially, customers will request a tour of our showroom via our website, the info gets stored in SQL Server and then internal users will use my app to view, approve, deny the requests.

It seems to me that I need a server appilcation so that all of the persistence and logic is in one place. Then I can have ASP.NET and Win Form clients connecting to perform the tasks that are needed.

By thick-client, do you mean that the entities along with the ORMSupport classes are deployed to each client pc? Kinda like I currently have it deployed?

dazedorconfused wrote:

As usual, thanks for the quick reply.

I guess I am trying to design this as a client - server app because I feel like I am supposed to. Essentially, I have an application that is becoming the "catch-all" for any functionality needed by my company that our EBS system doesn't meet. Its currently released and being used here and there. In its current state, I have a dll that consists of the genereated peresitence framework (self servicing), a dll where some custom validator classes live (for business logic) and a win forms exe.

Right now, I have about 50 users and two different modules in the application. One module allows users to view and modify Return Material Authorization requests before they are submitted to SAP. The back-end for this module is an existing java based server application. So, I talk to it using web services that are exposed in Apache.

The second module is still under development. Essentially, customers will request a tour of our showroom via our website, the info gets stored in SQL Server and then internal users will use my app to view, approve, deny the requests.

It seems to me that I need a server appilcation so that all of the persistence and logic is in one place. Then I can have ASP.NET and Win Form clients connecting to perform the tasks that are needed.

That indeed seems appropriate to me. This way you communicate data / commands back/from the client on the level of functionality, not on the level of data-access.

By thick-client, do you mean that the entities along with the ORMSupport classes are deployed to each client pc? Kinda like I currently have it deployed?

Yes.