Data tier on an application server

Posts   
 
    
Posts: 4
Joined: 08-Mar-2007
# Posted on: 08-Mar-2007 19:06:21   

I'm designing a new WinForms application using C#, .NET 2.0 with VS2005.

My initial design calls for all of the data access code to run in a middle tier on an application server. That is, it's a three tier application with each tier running on a physical CPU like so: [Layer C: SQL SERVER] <-[Layer B: DATA/BUSINESS] <- [Layer A: PRESENTATION] [A] calls [B] calls [C] [A] never calls [C] I like the fact that the presentation tier [A] doesn't need access to the SQL Server tier [C]. No client workstation connects directly to SQL Server.

I'm using .NET remoting and passing binary serialized objects between the middle tier and the presentation tier. It works well but requires me to hand code dozens of data access classes for the middle tier.

Then I discovered LLBLGen Pro and I love it. The problem is I don't see any good way to use it without breaking my model. In all of the examples the LLBLGen classes are running on the same CPU as the presentation layer. Is it possible to host the LLBLGen classes on a different CPU and marshal the objects out to the presentation layer? Is there a better way? Should I give up on hosting each tier on a seperate physical CPU and mash layer [B] and [A] together on every client workstation? [Layer C: SQL SERVER] <- [Layer B: DATA/BUSINESS <- Layer A: PRESENTATION]

jmeckley
User
Posts: 403
Joined: 05-Jul-2006
# Posted on: 08-Mar-2007 20:41:26   

you will want to use the adapter model. this seperates the entity objects from CRUD operations. your business logic would then use the adapter to fetch/save/delete entity[collections]. I know remoting is possible, however I have not constructed a project utilizing this method.

You have 2 options with your PAL accessing the BLL. 1. use the entity[collections] on all tiers. this will require the PAL to reference the DbGeneric and ORSupport assemblies. Your BLL would reference these assemblies along with the DbSpecific assembly. 2. create your own DTO for PAL to BLL communications. by creating DTO templates with template studio (part of LLBL with purchase of license) this isn't difficult. there are many posts on this topic alone.

I would opt for the 1st method. most of what you need is built into LLBL. why reinvent the wheel?

PilotBob
User
Posts: 105
Joined: 29-Jul-2005
# Posted on: 08-Mar-2007 21:07:37   

You might want to look at JCL which is a combination of CSLA for great portable business objects and the DataPortal uses LLBLGen to get the objects.

I am pretty user going 2 Tier or 3 Tier would just be a configuration change.

BOb

Posts: 4
Joined: 08-Mar-2007
# Posted on: 08-Mar-2007 22:06:03   

As I'm reading the LLBLGen documentation I see how to do x using adapter or do x using self-servicing. I don't see an explanation of what the two models are and when it's appropriate to use one over the other. I can see that the adapter model puts the database specific classes into a seperate project but there isn't much else to go on.

jmeckley
User
Posts: 403
Joined: 05-Jul-2006
# Posted on: 08-Mar-2007 22:08:59   

adapter is perfect for remoting, multiple db access, and finer control over the CRUD operations.

Self Server is easier to use as the save functionality is within the entity itself. there is a section in the docs (can't remember where) that outlines the differences.

in your situtation will require adapter since you don't want the PAL to know about the DAL.