n-tier design with "adapter" layer - keepin business layer clean...

[oliharvey]

Hi -
(not really a C# question -...apologies)

I seem to have gravitated towards a particlar design pattern - and
would welcome your opinions as to it's sanity - thanks...

The basic idea is that - in an effort to keen the Business Classes as
clean as possible - I have *totally* excluded any data load/
persistance code.

In my model a Data Adapter is used to load/persist the Business
objects eg:

Customer c = Adapter.LoadCustomer(id);

or

Customer c = new Customer(id);
Adapter.Hydrate(c);

Basically the Adapter acts as a bridge between Business and Data
aspects.

The UI gets nice Business Objects to work with, the Data Access Layer
returns only built in types (eg Dataset) and the Adapter marries the
two.

here's a piccie of my architecture:

UI
|
| --------------|
Bus Adapter
|
Data Access
|
Data Source

I don't think I've invented this myself - but googling only turned up
models where the following might be done:

Customer c = new Customer(id);
c.Load();

comments appreciated !

O.

[Alvin Bruney [ASP.NET MVP]]

I believe the terminology is provider not adapter. That's the best design in
terms of flexibility really because it allows you to separate concer... well
you already figured out what the benefits are. The only downside I impress
upon our architects is that there is added complexity and it may be overkill
for small to medium projects.

--

Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The O.W.C. Black Book, 2nd Edition
Exclusively on www.lulu.com/owc $19.99
-------------------------------------------------------
<ol*******@googlemail.comwrote in message
news:ed**********************************@k13g2000 hse.googlegroups.com...

Hi -
(not really a C# question -...apologies)

I seem to have gravitated towards a particlar design pattern - and
would welcome your opinions as to it's sanity - thanks...

The basic idea is that - in an effort to keen the Business Classes as
clean as possible - I have *totally* excluded any data load/
persistance code.

In my model a Data Adapter is used to load/persist the Business
objects eg:

Customer c = Adapter.LoadCustomer(id);

or

Customer c = new Customer(id);
Adapter.Hydrate(c);

Basically the Adapter acts as a bridge between Business and Data
aspects.

The UI gets nice Business Objects to work with, the Data Access Layer
returns only built in types (eg Dataset) and the Adapter marries the
two.

here's a piccie of my architecture:

UI
|
| --------------|
Bus Adapter
|
Data Access
|
Data Source

I don't think I've invented this myself - but googling only turned up
models where the following might be done:

Customer c = new Customer(id);
c.Load();

comments appreciated !

O.

[Frans Bouma [C# MVP]]

ol*******@googlemail.com wrote:

Hi -
(not really a C# question -...apologies)

I seem to have gravitated towards a particlar design pattern - and
would welcome your opinions as to it's sanity - thanks...

The basic idea is that - in an effort to keen the Business Classes as
clean as possible - I have *totally* excluded any data load/
persistance code.

In my model a Data Adapter is used to load/persist the Business
objects eg:

Customer c = Adapter.LoadCustomer(id);

or

Customer c = new Customer(id);
Adapter.Hydrate(c);

Basically the Adapter acts as a bridge between Business and Data
aspects.

The UI gets nice Business Objects to work with, the Data Access Layer
returns only built in types (eg Dataset) and the Adapter marries the
two.

here's a piccie of my architecture:

UI
|
| --------------|
Bus Adapter
|
Data Access
|
Data Source

I don't think I've invented this myself - but googling only turned up
models where the following might be done:

Customer c = new Customer(id);
c.Load();

comments appreciated !

This is exactly how our 'Adapter' paradigm works in LLBLGen Pro :)
CustomerEntity c = new CustomerEntity("CHOPS");

using(DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.FetchEntity(c);
}

so no persistence logic inside the entity classes. The advantage is
that UI developers can't make shortcuts to access data or persist data.
This also means that there's no lazy loading.

Most O/R mappers use this pattern with one exception: most o/r mappers
DO implement lazy loading in their implementation of the pattern, which
effectively means it somewhat mitigates the whole purpose of the
pattern. (also, most o/r mappers who implement this have a centralized
'context' or 'session' class which mimics the 'adapter'. However it also
does change tracking. An adapter IMHO shouldn't do that, it should leave
change tracking to the entities itself)

The other paradigm, i.e. with Load/Save etc. as methods on the entity
class is called 'SelfServicing', as we like to call it, as the entities
serve themselves: they can save/load themselves. Of course,
selfservicing does have lazy loading.

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#)
------------------------------------------------------------------------