Business Layer - Data Layer

  • Thread starter Thread starter David Gouge
  • Start date Start date
D

David Gouge

Hi all,

I hope this is a suitable group for this question. Feel free to push me
off to the correct one if not. :)

Basically i have been developing windows applications using Visual
Foxpro for about 5 years for a small software house and we will be
shortly moving to a .net (C#) solution.

Within our VFP applications there are no distinct application layers
whatsoever. Business logic, data access / manipulation and GUI code is
all lumped together on forms and program files. With our move to .net I
would like to implement more of a 3 teir architecture with the UI,
Business Logic and Data Access / Manipulation all separated out.

I understand completely the theory behind this, but am struggling
somewhat to grasp the practical details. If, for example, I have a
Client object in my Business layer, what would i need to do do access /
update data based on the theory that the Business layer does not have
any sql statements etc in it? Pass datasets between the two layers? Or
xml / web services?

If someone could give me a point in the right direction or let me know
of some good resources / books i would be most grateful.

Best Wishes,

David Gouge
 
Normally you pass some sort of a data object between the layers. This can be
either a custom class, a dataset, or whatever else you may desire. Just make
sure the object is serializable if you wish to pass it between processes.
Normally you would choose to keep the dataobjects in a separate dll you can
reference in each of the application layers.

How you separate the layers physically is another question, but the logical
separation is the basic prerequisite for physical separation.
You can either keep the layers together physically, simply instantiating
objects from different layers in the same application (application domain),
or you can run the layers in different processes (application domains -
applications, services, webservices,...), separating them with remoting,
webservice, msmq, or other facades (thin interop layers that facilitate
communication).

What level of physical separation you choose depends more or less on the
solution design requirements - security, system, network, performance, etc.
requirements that have to be taken into account - and, of course, personal
preference. There really is no general rule that would fit every approach.
Basically what you should remember at all time is to create your components
statelessly... keeping state is bad, especially with physical separation of
the layers, and designing for asynchronisity is a good approach for boosting
performance.

I would also suggest you look into MessageQueuing and
System.EnterpriseServices a bit... they are an often overlooked part of a
windows box which can solve quite a few problems regarding isolation of
processes and running different components in separate application domains
with different security & trust levels.

Otherwise, recommended reading would be found inthe Microsoft's Patterns &
Practices library, especially in the architecture center.
(http://msdn.microsoft.com/architecture/)

The specific topic of passing data through tiers is dealt with in the
"Designing Data Tier Components and Passing Data Through Tiers" guide, found
at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

I hope this helps you further.

Regards,

Ziga Jakhel
MCSD.NET
ziga.jakhel(a)rrc.si
 
Ziga said:
Normally you pass some sort of a data object between the layers. This can be
either a custom class, a dataset, or whatever else you may desire. Just make
sure the object is serializable if you wish to pass it between processes.
Normally you would choose to keep the dataobjects in a separate dll you can
reference in each of the application layers.

How you separate the layers physically is another question, but the logical
separation is the basic prerequisite for physical separation.
You can either keep the layers together physically, simply instantiating
objects from different layers in the same application (application domain),
or you can run the layers in different processes (application domains -
applications, services, webservices,...), separating them with remoting,
webservice, msmq, or other facades (thin interop layers that facilitate
communication).

What level of physical separation you choose depends more or less on the
solution design requirements - security, system, network, performance, etc.
requirements that have to be taken into account - and, of course, personal
preference. There really is no general rule that would fit every approach.
Basically what you should remember at all time is to create your components
statelessly... keeping state is bad, especially with physical separation of
the layers, and designing for asynchronisity is a good approach for boosting
performance.

I would also suggest you look into MessageQueuing and
System.EnterpriseServices a bit... they are an often overlooked part of a
windows box which can solve quite a few problems regarding isolation of
processes and running different components in separate application domains
with different security & trust levels.

Otherwise, recommended reading would be found inthe Microsoft's Patterns &
Practices library, especially in the architecture center.
(http://msdn.microsoft.com/architecture/)

The specific topic of passing data through tiers is dealt with in the
"Designing Data Tier Components and Passing Data Through Tiers" guide, found
at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

I hope this helps you further.

Regards,

Ziga Jakhel
MCSD.NET
ziga.jakhel(a)rrc.si
Click to expand...


Thank you so much for your concise reply. I'll be sure to have a look
at those articles you suggested. As I mentioned, moving from our 'one
big fat messy layer' in our vfp app to this more structured approach has
been giving me headaches, but your reply has helped a lot.

Thanks again,

Dave
 
Ziga said:
Normally you pass some sort of a data object between the layers. This can be
either a custom class, a dataset, or whatever else you may desire. Just make
sure the object is serializable if you wish to pass it between processes.
Normally you would choose to keep the dataobjects in a separate dll you can
reference in each of the application layers.
Click to expand...

Hi Ziga,

Again, thanks for the reply. Just one more detailled question if i may.

If I have my Client object in my business logic layer that has a method
LoadClientDetails(int ClientUnique) to fill the client object with data
from the underlying database, how would that be realised? For example,
before i understood the distinction between the layers i would have put
in the Client.LoadClientDetails method code to create a db connection
object, run some sql based on the ClientUnique and then use the
datareader (or whatever) to populate the object's fields.

Now I understand that business objects (strictly) must not have things
such as connections / sql inside them, so to get the client data i am
interested in, would i also need a corresponding method on an object in
the data layer that returns the client dataset? So in effect a call to
Client.LoadClientDetails() would result in the Client object making a
call to SomeDataObject.LoadClientDetails().

Or would the datalayer be more generic, and if so, the Client object
would then need to be specifying table / fields etc for the data layer
to return.

My head hurts. ;)

Thanks Again,

Dave
 
Hi, David!

An interesting question that demonstrates a common problem with multi-tier
solutions - plenty of pass-through methods, as you should not jump layers.

Let's assume your Client object is primarily a data carrier.

So, when you want to fill it with data, you:

1) Pass it to the BLL and call some FillClientWithData method there
2) The BLL method in turn passes the Client object down to the DAL, where it
actually gets filled
- or-
2a) The BLL gets data from the DAL through some other carriers (like
disconnected datasets) and transfers it into the Client object. (this could
also be done in a multi-layered DAL)

The call would be something like MyBLLObject.FillClientWithData(Client)
and the BLL object would go MyDALObject.FillClientWithData(Client), so yes,
you need appropriate methods in the BLL and DAL.

In this scenarion BLL actually does nothing "of value" by itself, but simply
pass the object back and forth, in fact acting as a facade for the DAL.
If you have a plain-vanilla data-entry or data-edit scenario, the BLL is
normall comprised mainly of DAL pass-through methods. The Business Logic
comes into play when you add data validation, lookups, data aggregation from
different sources, actual computational logic, etc,. into the BLL.

When developing a client component I usually compose it from an instance of
a data carrier class that is accessible from all layers and gets
transferred between the layers, and it's own logic that uses and manipulates
the data. So the Client, for instance, calls the BLL.FillMeWithData() method
and passes/recieves a DataCarrier object that it then processes. The BLL in
turn then calls the DAL, which goes to the DB, and so on. Objects on each
layer only know object from the next layer, that's how it should be. Only
common stuff such as data carriers, enumerators, etc. are usually
universally known and deployed in shared dlls.

Regards,

Ziga
 
Back
Top