nTier-distributed app... Is it possible? How?

Posts   
 
    
kingalef
User
Posts: 14
Joined: 10-Jul-2008
# Posted on: 10-Jul-2008 22:32:42   

Hi, I went through your docs and while I still need to wrap my head around a lot of the things explained, I could not find much on distributed applications. The scenarios described seem to essentially assume you have access to your DB and are "connected" applications (ala client/server). What I need is the ability to work connected or disconnected (sometimes for days) and be able to merge changes when my application reconnects. How is something like this doable with your framework?

Regards, Alessandro

daelmo avatar
daelmo
Support Team
Posts: 8245
Joined: 28-Nov-2005
# Posted on: 12-Jul-2008 06:08:05   

Hi Alessandro, here are some thoughts, please let me know if I explained myself correctly and understood your scenario:

n-Tier Well, LLBLGen generates for you the lower layer and the business layer (LL-BL), in top of that you could add more. So it's enough flexible. In this scenerio AdpaterTemplateSet is recommended.

Distributed That depends upon your project architecture. What are you planning to do (about distributed)?

Connected-Disconnected from Database (for days) Some people resolve this using two databases, one local and the main DB, for example CE and SQLServer. LLBLGen allows you to change the database at runtime. However you have to do the sync by your own code: detect whether you need to use local or remote server, change the target server, do sync (you could do this in a lot of ways, that depends on your infrastructure, your needs, etc).

David Elizondo | LLBLGen Support Team
kingalef
User
Posts: 14
Joined: 10-Jul-2008
# Posted on: 14-Jul-2008 19:20:46   

Well, nothing really out of the ordinary: it's a classic nTier system with client, middle tier server and DB. What LLBLGen produces is a nice OO data access framework but I need to know how to remote the data and ensure the client can continue using your object model even if the DB is not present (work offline, briefcase model). The networks we use are really unreliable and, in several scenarios clients might not be online for days at a time, so they need to be able to continue inserting data locally (in some sort of cache) and resync when online.

The local db crossed my mind, but since we use Oracle on the back end, this might not be so easy when we need to resynch the two entities. Also, the whole idea of an nTier app is to use a middle tier (which contains some of the business rules the whole system enforces), so I'd like to stick with that model.

I hope I made myself clear...

Thanks!

mattsmith321 avatar
Posts: 146
Joined: 04-Oct-2004
# Posted on: 14-Jul-2008 23:47:26   

kingalef wrote:

What I need is the ability to work connected or disconnected (sometimes for days) and be able to merge changes when my application reconnects. How is something like this doable with your framework?

kingalef wrote:

What LLBLGen produces is a nice OO data access framework ...

I think you kind of answered your own question. LLBLGen Pro is a nice data access framework. It does not provide a framework for solving connected/disconnected problems. Something like Google Gears or Adobe Air (or the previously mentioned local database option) is probably more suited to solving that particular problem-space.

LLBLGen Pro provides a couple of different ways/options to communicate with that data access layer (adapter vs. self-servicing, serialized vs. remoting, entities vs DTOs, etc.) that you can code against but it will ultimately be up to you to come up with the client-side architecture.

An interesting approach (without giving it too much thought and without checking to see if it would be a good idea or not) would be to have an LLBLGen assembly generated to talk to a local database (Access, Firebird, etc.) and then have an LLBLGen assembly that resides on the server and is generated for the backend there (SQL Server, Oracle, etc.). You would then have some glue code on the client and server that manages the communication between the two. Of course, that is a pretty simplified overview. I'm sure the details would be a lot more involved stuck_out_tongue_winking_eye

Matt