Why we need business logic layer?

[MS newsgroup]

I don't have clear reasons why we need business logic layer and data logic
layer instead of having only data logic layer.

Are there any good reasons for that?

 

[Scott M.]

Sure, there are plenty of reasons. The most important though is that if
anything about your business logic or your data logic changes (as always
happens), you can replace just one layer of code without having to disturb
the other.

The business layer is where your business rules are processed, the data
layer is where your data manipulation is done. Separating these also adds
another level of security to your applicaiton.

 

[Guest]

Well if you are building an application to track your CD collection at home
then you can do whatever you want.

However, in the corporate world where you have distributed applications that
are critical for performance, maintainability, and scaleability then you
would want to employ a good design model for your system.

Traditionally, the path is to use logical layers (sometimes they are
physical separations also).

You should shoot for logical partitioning (layers) and design using
interfaces as a contract between layers. Doing this will make it easier to
move your functionality. So, lets say you have a business component that must
do some pretty hefty math and lot's of CPU power and so you want to take
advantage of your corporate server that is a muscle machine with Duel Core
technology and ton's of RAM for such feats. It can host your business
component. However, if it was so tightly coupled with your data access
component you couldn't do this, thus it is not loosely coupled and highly
cohesive.

If you don't apply logical layers to your application it will result in
monolithic apps that are hard to maintain, make enhancements, and scale.

Maintenance would become a big problem because then it would be very hard to
size up the effect of any changes or enhancements you may make in one
component on the other components in the app.

Hope that helps.

 

[MS newsgroup]

however,
if there is only one data access layer then, it doesn't worry about other
lay automatically.
and if they want security reason it is managed easily using storedprocedure
easily.

are there any other good reasons?

 

[Jan Kucera]

But if the data model changes, I have to change the data layer as well as
the business layer, haven't I?

Which layers do you have, or what do you recommend to put in the individual
layers?

Jan

 

[Kevin Spencer]

How about reusability? The UI layer only knows about the business layer. The
business layer only knows about the data layer. Therefore, if you have
another project, you can re-use the data layer in that project.

Also, let's say that you have created a Windows Forms application. Now you
receive a requirement that the same application must be made available via
an ASP.Net web site. If you properly separate your UI layer from the
business layer, you can easily re-use the same business layer with the web
interface.

It's partially all about dependencies. The more independent a component is,
the more reusable it is. It's also about maintenance. But that's been
covered before. And extensibility (as per my example).

If you program for a few years, you'll figure it out all by yourself, via
the school of hard knocks. Once you're tired of having to maintain, debug,
and extend your own poorly-architected applications, re-inventing the same
wheels over and over again, you figure this stuff out for yourself. Or you
can take the easy way, and learn from those who already have the experience.

--
HTH,

Kevin Spencer
Microsoft MVP
Chicken Salad Surgery

It takes a tough man to make a tender chicken salad.

 

[Guest]

Well, as I said before you can use interfaces as a contract between your
components, this way if your data model changes thus it changes your data
access component it still won't affect your business component.

To Illustrate:
Lets say you have a system that shows products you offer.

You have three components:
1. Entities - Business entities component that has a class called
ProductInfo.
2. IDAL - This contains an interface class called IProduct that has a
GetProducts method that returns a list of ProductInfo classes from the
Entities component.
3. SQLServerDAL - This contains a class called Product that inherits from
IProduct thus has a method called GetProducts.
4. DALFactory - This has a class called DataAccess and has a method called
CreateProduct which returns an IProduct interface. This is your data factory
class.
5. BLL - This is your business logical layer and it has a class called
Product, which has a method called GetProducts. The method uses the
DALFactory.Access.CreateProduct method to get the appropriate data access
component to use, in this case its the SQLServerDAL component. It returns a
list of ProductInfo entities to the caller.

In this scenario you can have your Business layer use ANY data access layer
that inherits from IProduct. Therefore, if you currently use SQLServer but
now have to migrate to Oracle or your column naming conventions change, or
your stored procedures get renamed then your Business layer doesn't care
therefore the only thing you have to re-deploy is the data access layer. You
minimize regression testing, impact on other code, it is highly scaleable,
among a whole host of other benefits.

Hope this helps!

 

[Guest]

5 Components!!! I can architect an application but can't do math worth a
toot!

 

[Scott M.]

It doesn't matter that there is only one data access requirement. Business
logic is not the same a data logic. The business layer needn't and
shouldn't know where the data resides or how to access it. By separating
the layers, either layer can be reused, modified or replaced with minimal
impact on the other layers.

 

[Steve C. Orr [MVP, MCSD]]

This is a complex subject.
I suggest you read the following book which is widely considered to the the
authority on the subject:

Expert VB 2005 Business Objects (by Rocky Lhotka)
http://www.amazon.com/exec/obidos/A...14573&adid=0MN5QNXF4KW05MF3J962&link_code=as1

or here's the C# version if you prefer:
http://www.amazon.com/exec/obidos/A...14573&adid=0DX2YFNHQP6HRCVHN7X0&link_code=as1

 

[Scott M.]

But if the data model changes, I have to change the data layer as well as
the business layer, haven't I?

Not necessarially. It's actually quite rare (and not a good idea) to change
the database's interface (names of stored procs., table design, etc.). But
it is quite common to change databases entirely. So, if the "old" database
was, say, Oracle and the new one is SQL Server, your data layer would need
to be re-written for different data access, but the SP names as well as
input/output parameters don't neccessarially change. None of this need
affect the business layer at all.

Which layers do you have, or what do you recommend to put in the
individual layers?

It's pretty common to have (at least) a UI layer, a business layer and a
data layer.

UI layer - responsible for all aspects of the user's interface with the
application. This would be the web pages of a web based application or the
form or console of a client application. User input is validated here and
results and errors are formatted and presented here.

Business layer - business rules are processed here (i.e. functions that
BEGIN the process of getting, modifying and creating customer or vendor
data).

Data layer - usually called by the business layer methods. This layer
receives business layer data, connects to the data store and sends results
back to the business layer.

 

[Nick Malik [Microsoft]]

This is a complex subject.
I suggest you read the following book which is widely considered to the
the
authority on the subject:

Expert VB 2005 Business Objects (by Rocky Lhotka)
http://www.amazon.com/exec/obidos/A...14573&adid=0MN5QNXF4KW05MF3J962&link_code=as1

or here's the C# version if you prefer:
http://www.amazon.com/exec/obidos/A...14573&adid=0DX2YFNHQP6HRCVHN7X0&link_code=as1

Good answer, Steve. Now if I could only get our more experienced developers
to actually read the books, and understand them, I'd be one step further
ahead.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Jan Kucera]

Not necessarially. It's actually quite rare (and not a good idea) to
change the database's interface (names of stored procs., table design,
etc.). But it is quite common to change databases entirely. So, if the
"old" database was, say, Oracle and the new one is SQL Server, your data
layer would need to be re-written for different data access, but the SP
names as well as input/output parameters don't neccessarially change.
None of this need affect the business layer at all.

Actually my data layer uses DbConnection, DbCommand and others class which I
suppose are independent of the database engine and it takes the concrete
connection objects in a constructor. Is this a bad idea? Aren't the Transact
SQL statements compatible between Oracle, SQL server and others?

Thanks,
Jan

 

[Joerg Jooss]

Thus wrote Jan,

Actually my data layer uses DbConnection, DbCommand and others class
which I suppose are independent of the database engine and it takes
the concrete connection objects in a constructor. Is this a bad idea?
Aren't the Transact SQL statements compatible between Oracle, SQL
server and others?

Only the parts that are part of ANSI SQL (or where the syntax happens to
be identical outside of any standard). Using an abstraction layer for the
actual database implementation can induce a false sense of portability...

Cheers,

 

[Kevin Jones]

What if your database wasn't a database but was the file system?

I'm writing software at the moment where the data could be stored
directly on the file system, or in the database.

My rule-of-thumb is "Don't have a 'domain specific' code in the business
layer" Where 'domain specific' means ADO/ASP/whatever code,

Kevin Jones

 

[Scott M.]

Exactly! I've been referring to databases, but your point IS the point. By
separating the data access layer from the business layer, you *could* switch
data stores without upsetting the business layer.

 

[Registered User]

Sure, there are plenty of reasons. The most important though is that if
anything about your business logic or your data logic changes (as always
happens), you can replace just one layer of code without having to disturb
the other.

The business layer is where your business rules are processed, the data
layer is where your data manipulation is done. Separating these also adds
another level of security to your applicaiton.

I prefer a 'translation' layer between the business and data layers.
This extra layer tends to be very thin and solves the issue of how and
where data gets turned into objects and vice versa. Changes to either
the business or data layer are reflected in the translation layer. The
isolation becomes pretty complete, the business layer knows nothing
about data objects and the data layer knows nothing about business
objects.


regards
A.G.