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.
architecturelayered architectureAsp.Net 2.0debate
Mohammad Ashraful Alam
Software Architect
Blog: [ http://blog.Ashraful.net ]
Portfolio: [ http://www.Ashraful.net ]
Microsoft ASP.NET MVP 2007-2008-2009
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.
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.
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.
Please mark the most helpful reply/replies as "Answer".
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.
architecture.net 2.0layered architecturedebate
Mohammad Ashraful Alam
Software Architect
Blog: [ http://blog.Ashraful.net ]
Portfolio: [ http://www.Ashraful.net ]
Microsoft ASP.NET MVP 2007-2008-2009
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.
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...
There are a few benefits of implementing layering for separation of concerns I have not really seen mentioned, yet.
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.
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.
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).
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.
joycsharp
Member
16 Points
12 Posts
Debate: Do We Really Need Three Layer Architecture?
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.
architecture layered architecture Asp.Net 2.0 debate
Software Architect
Blog: [ http://blog.Ashraful.net ]
Portfolio: [ http://www.Ashraful.net ]
Microsoft ASP.NET MVP 2007-2008-2009
benhart
Participant
818 Points
179 Posts
Re: Debate: Do We Really Need Three Layer Architecture?
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.
kaushalparik...
All-Star
26568 Points
3692 Posts
MVP
Re: Debate: Do We Really Need Three Layer Architecture?
Nov 04, 2008 07:52 AM|LINK
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.
[KaushaL] || BloG || Twitter
Don't forget to click "Mark as Answer" on the post that helped you.
RazanPaul
Member
2 Points
1 Post
Re: Debate: Do We Really Need Three Layer Architecture?
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.
jimibt
Member
724 Points
185 Posts
Re: Debate: Do We Really Need Three Layer Architecture?
Nov 04, 2008 08:25 AM|LINK
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').
jimi
anonymouse
Participant
1014 Points
233 Posts
Re: Debate: Do We Really Need Three Layer Architecture?
Nov 04, 2008 08:34 AM|LINK
joycsharp
Member
16 Points
12 Posts
Re: Debate: Do We Really Need Three Layer Architecture?
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.
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.
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.
architecture .net 2.0 layered architecture debate
Software Architect
Blog: [ http://blog.Ashraful.net ]
Portfolio: [ http://www.Ashraful.net ]
Microsoft ASP.NET MVP 2007-2008-2009
benhart
Participant
818 Points
179 Posts
Re: Debate: Do We Really Need Three Layer Architecture?
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.
jimibt
Member
724 Points
185 Posts
Re: Debate: Do We Really Need Three Layer Architecture?
Nov 04, 2008 09:30 AM|LINK
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!!
jimi
jferris
Member
31 Points
9 Posts
Re: Debate: Do We Really Need Three Layer Architecture?
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,