Get Help:Ask a Question in our Forums|Report a Bug|More Help Resources
Last post Nov 12, 2008 12:16 AM by LudovicoVan
Nov 04, 2008 06:14 AM|LINK
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.
Nov 04, 2008 07:44 AM|LINK
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.
Nov 04, 2008 07:52 AM|LINK
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.
Nov 04, 2008 08:20 AM|LINK
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.
Nov 04, 2008 08:25 AM|LINK
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').
Nov 04, 2008 08:34 AM|LINK
Nov 04, 2008 09:11 AM|LINK
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.
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.
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.
Nov 04, 2008 09:16 AM|LINK
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.
Nov 04, 2008 09:30 AM|LINK
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!!
Nov 04, 2008 01:45 PM|LINK
There are a few benefits of implementing layering for separation of concerns I have not really seen mentioned, yet.
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,