How many of you changed your database vendor (i.e. Sql Server, Access) after developing an application? How many of your data entities include business logic? I could say, less than 10% in both cases for my case. I found the similar statistics for my other known developers. I guess this is true for less that 10% of the developers around the world.

If that’s true, then do we really need to consider Three Layer Architecture (commonly UI, Business Logic and Data Access Layer) as the best practice? Isolating data and business logic can’t be a good logic, if I know for sure my database vendor is not going to be changed, then why we need another layer? To write cohesive (relevant to the meaning of class name) classes? Why don’t we create classes for business logic to a separate layer, only for the entities which includes business logic?

Is not it enough to have only two layered (UI and Data Access Layer)? Reducing one additional layer for each entity can increase our productivity and reduce the overheard. I think this is a serious debate and needs some solid discussion. 

You raise some interesting points. I agree in some cases, if you're writing simple systems that are little more than 'forms over database tables', having a dummy business logic layer is a complete waste of time. But I think many people have missed the point when it comes to the BLL, and simply have it as a filter through with entities pass. This common architecture is similar to the Pet Store, in which entities shapes are defined in a common assembly, and there would be a corresponding BLL and DAL, which does various things to it. I agree that this architecture is wasteful.

Put simply, I've taken to incorporating business logic into my entities instead. Then you get to the reduced waste you're describing, but still a good separation of concerns. I used to be in a "pet store" architecture frame of mind, until the waste and inability to handle complexity broke me down.

Also, one needs to consider the life span of a system. You statements regarding not changing vendor etc. can only ever be true for the short term. I've worked with ancient systems, impossible to modernise without complete rewrite because people made the same assumptions you're making. Taking a few steps early on to future proof your application is essential if you're building a system that is intended to last.

Look forward to the discussion, will be interesting to hear some more perspectives.

Hello Ashraf,

Why to only think about "just possibility of changing database vendor" ??

we also need to think about flexibility of code, maintenance and reusablitiy of code, neat and simple migration of any module into another interface/application without any hurdle; and overall team work would be optimzed as perellel development would be possible of individual tier by perticular specialist developers. if we take an example and remove business logic layer and put everything at database access side; then it will be loaded with applying business rules. layers helps us to share load and improve performance of servers (database and application) and client.

Yes, we need. DB change and entities with business logic are not the only reasons for Three Layer Architecture. The actual cause is cohesion. In other words, There are many other reasons to do so: Reuse classes in completely new contexts, Make our classes easier to consume by other developers by hiding the ugly inner workings of our classes behind well-designed APIs, Isolate potential changes to a small area of code, Make the code easier to maintain and read, to reduce duplication in the code.

hi joy,

good topic, tho' not 100% certain that you're not playing devil's advocate here. . The two previous replies more or less echo my thoughts, so i won't repeat those. Instead, i'll gve a current real life example of how our 'shop' has succesfully used this 'layered' approach with a demonstrable ROI. we used to 'lease' one of our main databases from a 3rd party at a considerable cost. the benefit (in the past) of this had been that we didn't need to have inhouse expertise to administer the database PLUS, the original application was a green screen 4GL app. over the years, we have merged our (originally vb6, now c#) code over the top of this database api and were able to leverage all the good functionality that the 3rd party provided. we approached this (even in the vb6 days) by creating a BLL to handle the interaction between the client front ends (UI and BLL written by us) and this 3rd party database api. however, 2 years ago when the renewal for the lease was known to be due, we took a decision to develop our own backend for the main applcations that had relied on this 3rd party solution. as we had been developing all of our code in a structured BLL/DAL methodology, it was fairly easy to migrate the provider (DAL) away from the ingres 3rd party database to the sqlserver database that we developed inhouse. Now, had we not used a layered approach, we'd have been tied into the 3rd party solution until we rewrote the entire application suite (there are reporting apps as well as front and back of house apps). as it was, we kinda hit lucky and had some minor changes (8-10% of our migraton effort) required of the BLL but most of our efforts were directed at the migraton of the functionality in the new DAL. the total cost savings in yr 1 alone (dev accounted for) was a staggerring 500k (GBP). While we were at it, we did some much needed tweaks on the UI but could have got away with doing nothing at all!!

needless to say, this pushed the buttons of those higher up the food chain (i.e., the business heads) and you can now hear them in meetings asking if we are using a layered approach on their new developments .

i'm sure there are many similar stories out there but this is one that is so recent in my experience that it has a spooky resonance. I dread to ponder the scenario had we not taken steps many years ago to 'futureproof' our business logic (who knows, maybe our next DAL will be in the 'cloud').

I would say yes you do need three layers from my own experience having worked on enterprise level solutions. The physical separation having the layers on separate servers has paid dividends for us. The ability to have developers work solely on business logic and business cases without having to be involved in database issues has also worked in our favour. Having developers working on Unit testing the BLL without using the database has in the dev teams opinion encouraged the team to encapsulate and write unit tests that test a single function or element of the system. Just some reasons we have used used multiple layers in the past.

So far, few replies include the reality that we can’t really ignore the possibility of having new database vendor in future. Well, first it happens really rare to switch from one database vendor to another, and I guess 95%+ ASP.NET applications are using SQL Server as database vendor, which has been changed rarely. Having an upgraded version of SQL Server will not let developer to write a complete new data access layer. Although rare, but if the database vendor get changed to a separate vendor, but having additional Business Logic Layer will not help you not to write a complete new data access layer.

RazanPaul:

Make our classes easier to consume by other developers by hiding the ugly inner workings of our classes behind well-designed APIs, Isolate potential changes to a small area of code

 

If you use good data access utility methods, there is a rare chance that your data access codes get ugly. Also, if you consider pure object oriented development, developers at UI layer don’t really need to see your data access code, but needs to see the structure of those classes.

RazanPaul:

the code easier to maintain and read, to reduce duplication in the code.

 

Few have mentioned, having additional business layer will help to maintain code easily, which is totally fuzzy, having a useless layer will include some additional overhead of maintenance, nothing but this. “reduce duplication” is totally happens when you don’t have an useless business logic layer actually, as generally methods in business logic layer call the corresponding or similar functions of the data access layer.

Lastly, one reply said, having three layers helps to make the application scalable (by deploying into separate physical machines), and well I agree in this point, however that really can be considered when you have that possibility for that much HIGH VOLUME traffic. Furthermore, regarding current availability of high configurations of the servers, having two tiers dedicated to UI and Data Access Layer can easily handle millions of users per day easily and if you need more support for high volume traffic, then that’s special and obvious to have three layer model.

Personally I am in favor of using Three Layer Architecture (or even more, such as Façade Layer, Cache Layer, SOA Layer in addition to UI, BLL, DAL), but ONLY when we need it. Three Layer Architecture has been such a hype/buzz word that most of the developers are using/implementing it without understanding that, if they really need it, and thus violates two primary software development principle: KISS (Keep It Simple and Stupid), as addition useless Business Logic Layer reduces simplicity and YAGNI (You Ain't Gonna NeedIt), as you don’t have any business rule of the corresponding entities and you have the similar interface exist in Data Access Layer.

 

 Well if I can hop back in, and play a little devil's advocate myself...

I agree whole heartedly with every comment made. But the pattern is clear, the separation into these concerns ensures greater maintainability, ability to change with time, and greater reuse.

Adopting the "layered architecture" doesn't actually guarantee that. Done incorrectly you can find yourself with the same mesh of code with low cohesion and high coupling. I've seen BLL classes with nothing in them, just more coupling to instance or static calls to the corresponding dal code. This to me is the waste I referred to, you have another class implemented to follow a pattern, but which serves no purpose, and still needs to be maintained. If you have a lot of these you might wish to consider why.

Many people are shocked to find out how much of a mission it actually is should you need to swap out database, even if these supposed layers are in place (I've been in that 10% a few times, and will be again, I think your stats might be skewed ).

Also, remember that the database server doesn't need to change to encourage a DAL rewrite, all that needs to is the preferred data access solution. In the last 6 years we've seen a few versions of ado.net, 3 versions of sql server, the rise of WCF encapsulating databases, LINQ (and all related data providers), Entity Framework, a growing adoption of other ORMs, object databases getting more popular, and more! Most systems I build have a lifespan of between 5-10 years. I've worked with and against systems in banks that have been operating for over 20. Dataaccess has changed quite a lot in the last 20 years!

So in summary, layering alone doesn't ensure maintainability, but it's a massive step in the right direction.

And I do concede that in certain rare situations, maintainability might not be a concern. There are situations where the lifespan of a system is so short, the opportunity for reuse so marginal, chance of change so slim, the requirements so simple and the required time-to-market so tight that's it's excusable to just throw something together (hell, even skip the DAL, let's just use some sqldatasources!). I don't imagine this all comes together often, though.

 

joy,

not sure about the stats (95%), but my experience has shown that if that were the case, then that 5% most certainly would take you 95% of your effort if you did need to change over and didn't have a good structured architecture in place. my own experiance bears this out and unless you've been down this path in an enterprise situation, then i think we're really just having an after dinner dabate...

enjoyable all the same!!

 There are a few benefits of implementing layering for separation of concerns I have not really seen mentioned, yet.

1. Testability - We are adopting test-driven development.  Logical separation on all levels, whether it is a layer or the assemblies within a given layer, make it easier to leverage unit testing.  Similar tests live in close proximity to each other, setup and teardown methods often are highly reusable, and working within defined parcels of the code keep development on task - often through exposing underlying problems in related functionality.
2. Versioning - Not just seperating into layers, but sub-dividing layers into multiple assemblies based upon the potential for code churn make logical boundaries in assembly versioning.  Most people are looking at the DAL and BLL as being singular in usage, while it is very possible that multiple "applications" can reuse these layers.  For example, if you have a web site that is largely read-only, but you have a desktop content management tool that is both read and write, are you going to want to maintain two seperate DALs and two sets of unit tests for them?  Based upon how you logically structure your code, the same rules apply for reuse in business logic, as well.
3. Deployment - Once again, layering and sub-layering (what I personally refer to the multiple assembly breakdown as), means that you can test smaller portions of the code with higher accuracy and have fewer physical files to deploy.  This limits risk and time (which equals money).
4. Scalability - A layer can be distributed on separate physical hardware, and accessed through remoting or by adding a simple facade to create web methods.  If the presentation layer is lightweight and can live on a single server, but the business logic can not, this approach allows you to set up a web farm of business logic servers.

I think the point is that it is going to be different things to different people.  If you are kicking around a personal project, it might be overkill.  In my own personal projects, however, I find just the opposite.  I tend to focus more on the architecture so that the application is easier to maintain in the long term.  How it becomes interesting though, is noticing the distribution of work in a project.  Using a real world example, for any iteration, I currently see the current type of breakdown:

5% - UI Changes (New functionality and fixes)
60% - BLL Changes (New functionality (mostly) and fixes)
35% - DAL Changes (Mostly new functionality)

Some smaller iterations see no presentation changes, some see now DAL changes, and sometimes both is true.  By developing and testing around layers, we can focus our testing efforts just on the areas impacted and release a higher quality build.  Our main application right now is still largely without these layers.  Over the last year, we have taken on a massive refactoring effort to bring stability and ease of development and testing to the codebase.  I have actually been maintaining numbers to tell me what the percentage of defects are per 1000k lines of code in both the "legacy" application, and the new layers that have been added on top of it.  What is very interesting is that we are seeing a defect rate of around 15/1000k in the legacy application and 4/1000k in the layers that have been implemented through the refactor.  These defects are based upon tester-initiated and customer-initiated defects.

We are approaching a rewrite of our core and building new products around the core in the near future, and the validation that we have seen, not only in defect rate, but in things like maintainability, deployability, etc., have solidified the approach that we are going to take.  The defect rate is very important, though.  The cost of a defect grows, depending on where it is isolated.  If the defect is isolated in code review, it is substantially less expensive to fix than when it is caught by a tester, which in itself is less expensive than when caught by a customer.

Additionally, I don't even think that the number of layers should be thought of as a finite number.  There are many other types of "layers" that can be taken into consideration, such as a web service layer that acts as a facade on top of the BLL, a distributed caching layer, etc.  In my opinion, I think it honestly just comes down to using the right tools for the job.  A "two layer" approach is limited in usefulness for larger, enterprise applications, while a multi-layer, multi-tiered application might be overkill for a personal web site.  It comes down to finding balance.  I think the larger problem is that people get fixated just on a single type of approach and use it for all things.

All in all, YMMV,

Joseph,

Very nicely put and agreed, the testability and metrics centred on defects can only be truly measured when you have a real life example running in parallel. In my earlier comment, i alluded to the fact that i thought that joy was playing devil's advocate - i sincerely hope he was as there are so many advantages thrown away by ignoring real world experiences, many of which have been presented in this short (but growing) support (justification??) of adopting a 'layered' approach to your developements.

Having looked at your Blog (joy), i reckon you were playing this game to get content for a blog article entitled:

Do We Really Need Three Layer Architecture?

.

cynical to the core...

 

 >> Debate: Do We Really Need Three Layer Architecture?

I would say it also(really) depends on size/scale, extensiveness/measure of the application. obviously, I would not maintain three tier architecture for a hundred hours of application. moreover, from mouth-to-mouth, the definition of 3-tier architecture is different. in short, to have all benifits of which are discussed above in some posts, we need to use layered (not three always) architecture.

Three layer architecture is not about changing database or venders. Each layer has a special purpose a responsibility that it must fulfill. Every application has some business logic. Even the most simplest application of adding a user to the database has business logic for validating the customer, checking if the user already does not exists in the database etc.

By creating different layers you also make your application portable. Let's say anyone wants to use your BusinessLogic layer simple give him the assembly and that's it. Off course you don't have to create separate projects for each layer but it is a recommended practice. 

From an agile perspective layering allows you to unit test the application. You can write domain level tests on your business objects. You can write UI tests on your views and you can write integration level tests or acceptance tests by combining all the layers. 

The question that if the application must have three layers! NO it is not a must. But layers help to isolate the code which then becomes easy to test.

Remember an application without unit tests is a legacy application. 

Thanks all of have such valuable opinions.

However, I am in favor of using UI, Business Layer and Data Access Layer, for the entities which includes Business Rules. And it is not arguable that having this separation of concern will greatly help to increase the testability, maintainability and so on. Now we need to consider whether we need to consider Tight or Loose Intimacy between Layers.

For instance we have two data/business entities: School and Student, where we have some business rule included in School entity, where as vthe Student entity doesn’t have. For a “Tightly Intimate Layered” model, we may have SchoolBLL, StudentBLL at business logic layer, following which we’ll have SchoolDAL and StudentDAL at data access layer. For a “Loosely Intimate Layered” model, we’ll have SchoolBLL only in business logic layer along with SchoolDAL and StudentDAL.

Please have your own preference and cause with regard to Tight VS Loose Intimacy between Layers.

We all debate from our expirience with past applications right?  That is what I do.

 Do I need a 3 tiered architechure?  Sometimes yes,  sometimes even more layers (Model, View, Presenter, Service, etc).  Sometime I need an add-in structure.  Sometimes I can do everything in a simple 10 line click event.  It all depends on the size, scope, and complexity of the application. 

If I can rewrite the entire application in 4 hours or less by myself -- I don't care how many layers you have because I'll probably just rewrite it anyway. 

If that is not the case, I want unit tests.  Testability is important!  The more complex the application, the more important the tests.  Even bad tests are useful.

The more complex the application, the less I want to have to think about how the data is stored.  The more I employ DDD.  The later I create database tables and the like.

Also, I've had many applications where I've changed the database mid-stream.  I'd say that happens 25% of the time for me (which is way to often, the that is the type of clients that I get).

--------------------------

To another point. You also talk about having business logic in your entities.  I do not use that model.  My business logic happens either in the service layer or presentation layer.  I want my entities (domain objects) just to hold data.  That said, I will put simple data manipulation functions in my domain objects to make them easier to use else where (they might have a firstName/lastName properties, but not a FullName, so I'll do that there).