Wrox Programmer Forums
|
BOOK: ASP.NET Website Programming Problem-Design-Solution
This is the forum to discuss the Wrox book ASP.NET Website Programming: Problem - Design - Solution, Visual Basic .NET Edition by Marco Bellinaso, Kevin Hoffman; ISBN: 9780764543869
Welcome to the p2p.wrox.com Forums.

You are currently viewing the BOOK: ASP.NET Website Programming Problem-Design-Solution section of the Wrox Programmer to Programmer discussions. This is a community of software programmers and website developers including Wrox book authors and readers. New member registration was closed in 2019. New posts were shut off and the site was archived into this static format as of October 1, 2020. If you require technical support for a Wrox book please contact http://hub.wiley.com
 
Old August 11th, 2005, 03:39 AM
Authorized User
 
Join Date: Mar 2005
Posts: 36
Thanks: 0
Thanked 0 Times in 0 Posts
Default Is it worth have sperate data and business layers

I love the notion of n-tier architecture. Functionality can be spread accross the layers and changes in one layer shoudl not affect another.

However, as I develop my application, i am becoming more and more frustrated with the speration of the business and data layers.

Just imagine, I need to add another field to my database. I would have to change data class, business class, and all the presentation classes.

I am thinking I should just revert back to having one business class which should connect to database and apply the business logic. It would definetely cut back the amount of work.

Data layers are really useful if i am using my system on multiple devices, such as brosers / PDA ...

What do u think????

 
Old August 11th, 2005, 07:22 AM
Friend of Wrox
 
Join Date: Jun 2003
Posts: 917
Thanks: 0
Thanked 0 Times in 0 Posts
Default

You're asking the right questions about n-tier designs. It is certainly easier with small-to-medium systems to put all of the business logic in code-behind files, or closely-coupled utility classes.

However, long term maintenance of the site is much easier if the tiers are separated, or if you have a very large site.

Advantages of n-tier:

1) scalability - you can add data caching at several possible places without disrupting code in other tiers
2) maintainablity - you can modify code in one tier without breaking code in other tiers. It is understood that this doesn't fully apply to cases where you modify the underlying data elements. However, if your business logic is not tightly coupled to your DB schema, it is often possible to make schema changes that don't break lots of code. Things like "select *" is an invitation to disaster if the columns change, by the way.
3) security - you can implement security checks in several tiers to help stop hackers.
4) portability - it's easier to change DB platforms, or to re-use business components in other applications.
5) de-coupled tiers can allow developers to specialize. For example, many larger companies have developers who only do presentation level coding, or some that only do data tier coding.
6) you can modify the architecture to re-implement some functionality in new ways: maybe a web service, or remoting could replace a middle tier component. This is what Service Oriented Architecture is all about.

There are other advantages, and some disadvantages you didn't mention. Most companies strongly perfer the n-tier models for medium to large scale systems. Small systems are often on a short timeline and it's hard to develop and implement an n-tier design in only a few days.

Eric
 
Old August 12th, 2005, 04:35 AM
Authorized User
 
Join Date: Mar 2005
Posts: 36
Thanks: 0
Thanked 0 Times in 0 Posts
Default

100% correct :D






Similar Threads
Thread Thread Starter Forum Replies Last Post
Is it worth the price? Spivonious C# 4 August 11th, 2004 03:32 PM
Mixing Data access logic and business logic polrtex BOOK: Professional Jakarta Struts 0 December 15th, 2003 07:19 PM





Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Copyright (c) 2020 John Wiley & Sons, Inc.