Persistence/Broker Layer questions

[dkode]

Hello,

I am laying out the architecture for a very large website that will
scale to a very large degree.

I have a couple of questions before I attempt to go and implement a
Broker/Persistence Layer.

1. With a broker layer, does this layer sit at the same level as the
Business Layer? So to speak, the presentation layer has knowledge of
both BL and PL? and then ONLY the PL has knowledge of the DataLayer?
Correct?

2. Should the Persistence layer be handled as a Singleton object?

3. Initially I am envisioning that I will have an encrypted cookie on
the client side that only holds the users unique id, then upon postback
the presentation layer gets the User business object from the
persistence layer and the persistence layer saves the object to Cache.
Is this correct?

Up to this point when creating apps, I was always a little
uncomfortable with mixing all the data persistence in the business
layer, thats why I think this approach is much more appealing.

Any other pointers before I embark?

Thanks for your help guys!!

Sean

 

[Joanna Carter [TeamB]]

"dkode" <[email protected]> a écrit dans le message de (e-mail address removed)...

| 1. With a broker layer, does this layer sit at the same level as the
| Business Layer? So to speak, the presentation layer has knowledge of
| both BL and PL? and then ONLY the PL has knowledge of the DataLayer?
| Correct?

Strictly, the PL should have no knowledge of the DataLayer, only of the BL.
The DataLayer should only know about the BL by using reflection to examine
any objects passed to it or to create objects to fulfil requests from the
BL.

| 2. Should the Persistence layer be handled as a Singleton object?

Usually.

| 3. Initially I am envisioning that I will have an encrypted cookie on
| the client side that only holds the users unique id, then upon postback
| the presentation layer gets the User business object from the
| persistence layer and the persistence layer saves the object to Cache.
| Is this correct?

I don't know about web apps, sorry.

| Up to this point when creating apps, I was always a little
| uncomfortable with mixing all the data persistence in the business
| layer, thats why I think this approach is much more appealing.

You are correct in avoiding mixing data with BOs, it simply isn't necessary.

Joanna

 

[Frans Bouma [C# MVP]]

Hello,

I am laying out the architecture for a very large website that will
scale to a very large degree.

I have a couple of questions before I attempt to go and implement a
Broker/Persistence Layer.

write your own? It's not a walk in the park

1. With a broker layer, does this layer sit at the same level as the
Business Layer? So to speak, the presentation layer has knowledge of
both BL and PL? and then ONLY the PL has knowledge of the DataLayer?
Correct?

It's often preferred in larger applications to not have the PL know
anything about the persistence logic. This leads to the advantage that
the team which works on the PL tier can't bypass BL tier functionality.

2. Should the Persistence layer be handled as a Singleton object?

depends. In a persistence layer where the meta-data is located in
data, it's preferred to have a singleton, to avoid having to reparse it
every time a call to the db has to be made. In a persistence layer
where the meta-data is located in code, you don't have to use a
singleton object.

This can have the advantage that the persistence layer is pure
stateless, which means that it doesn't cache tracking info of an
entity as well. This is preferable in webfarms/serverfarms where entity
E is loaded on server X but persisted on server Y and you of course
don't want Y to see E as a new entity.

3. Initially I am envisioning that I will have an encrypted cookie on
the client side that only holds the users unique id, then upon
postback the presentation layer gets the User business object from the
persistence layer and the persistence layer saves the object to Cache.
Is this correct?

The persistence layer retrieves the object because the BL tier tells
it to do that, which comes from the PL tier. the object itself is
transported back to the PL tier. What happens there with the object is
the business of the PL tier. So if it wants to cache it in the
webserver's cache, it can do that of course.

Up to this point when creating apps, I was always a little
uncomfortable with mixing all the data persistence in the business
layer, thats why I think this approach is much more appealing.

You can always mix it of course. It's often more convenient, though
also keep an eye on the separation of functionality accessable by the
various teams in your application. As it's a large application as you
said, it's often developed by subteams and my experience is that it's
often preferred that the GUI team isn't able to fetch/save data from
the DB, only through a tier that's setup for that, so that you can be
sure no shortcuts are made to avoid check logic / bl rules.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------