n - tier... *religious question* [modified]
-
N tier development is the common practice of dividing your apps into layers that typically run on 2 or more tiers. Traditionally, these tiers are presentation - business layer - data layer. Where you basically wind up with a gui or guis that use business objects in the business layer to do things (usually involving the data layer -- though the business logic could also use service layer for other interactions). I originally was a pretty strong believer in creating a set of business logic classes that would comprise the business layer. Basically a set of object - relational mapping classes that provided some degree of mapping from database structure to business entity. However, over the past couple of years and sets of projects, I have become more a fan of hosting business logic in the database and exposing it through stored procs. This is a semi-religious debate. I now believe that a good way to do things, especially if you do not have to support multiple database platforms, is to create your database structures and then to factor your business logic/data access into stored procs and user defined functions. Your applications then interact with a very lightweight ado.net access layer to interact with this stored proc database interface. So your *business layer* is essentially in the database. I have used this for all sorts of reasonably complex systems. I believe this is a better way to develop systems than creating a bunch of classes that map tables. I also believe it is more efficient as you can keep your logic very close to the data and only return stuff that your guis are interested in displaying. Some people argue this is less scalable and creates a bottleneck on the database. I don't buy this as you can use pooling or if you really need to, clustering to eliminate this factor. Even if you do the business layer seperately as classes/services and host them on app servers, you can wind up with a bottleneck there. Plus a bunch more code, etc to support/worry about. Some people argue that TSQL is a different skill set from what developers have. I don't buy that either. Developers (atleast smart ones) are broadening their skill sets very much. The difference between a dev and dba is not significant in many cases especially regarding table design and stored proc development (yes there are many optimizations, server admin tasks better left to a dba, I'm not dismissing that). So a decent dev should know SQL very well in addition to their app dev language/s. And lets not forget the p
-
N tier development is the common practice of dividing your apps into layers that typically run on 2 or more tiers. Traditionally, these tiers are presentation - business layer - data layer. Where you basically wind up with a gui or guis that use business objects in the business layer to do things (usually involving the data layer -- though the business logic could also use service layer for other interactions). I originally was a pretty strong believer in creating a set of business logic classes that would comprise the business layer. Basically a set of object - relational mapping classes that provided some degree of mapping from database structure to business entity. However, over the past couple of years and sets of projects, I have become more a fan of hosting business logic in the database and exposing it through stored procs. This is a semi-religious debate. I now believe that a good way to do things, especially if you do not have to support multiple database platforms, is to create your database structures and then to factor your business logic/data access into stored procs and user defined functions. Your applications then interact with a very lightweight ado.net access layer to interact with this stored proc database interface. So your *business layer* is essentially in the database. I have used this for all sorts of reasonably complex systems. I believe this is a better way to develop systems than creating a bunch of classes that map tables. I also believe it is more efficient as you can keep your logic very close to the data and only return stuff that your guis are interested in displaying. Some people argue this is less scalable and creates a bottleneck on the database. I don't buy this as you can use pooling or if you really need to, clustering to eliminate this factor. Even if you do the business layer seperately as classes/services and host them on app servers, you can wind up with a bottleneck there. Plus a bunch more code, etc to support/worry about. Some people argue that TSQL is a different skill set from what developers have. I don't buy that either. Developers (atleast smart ones) are broadening their skill sets very much. The difference between a dev and dba is not significant in many cases especially regarding table design and stored proc development (yes there are many optimizations, server admin tasks better left to a dba, I'm not dismissing that). So a decent dev should know SQL very well in addition to their app dev language/s. And lets not forget the p
I'm curious why you would ask your question in this way. From your experience, putting business logic into the database works. It doesn't work for everybody, but it works for you. There's really no point in anybody trying to persuade you to change how you write your applications because ultimately you'll stick with what has worked for you for years and has put food on your table. I think developers should keep an open mind and use the skillsets of the team they have. Working in a heterogenous environment with 3rd party vendors, mainframe, and different dbs would necessitate a middle tier. Using a single database with a small application, you can get away with skipping the middle tier, and a lot of companies do this. If your programmers are experienced with SQL, use that. If you've got a bunch of kids fresh out of college, you may want to stick with a middle tier so they can use their OO skills. It's all relative.
-
I'm curious why you would ask your question in this way. From your experience, putting business logic into the database works. It doesn't work for everybody, but it works for you. There's really no point in anybody trying to persuade you to change how you write your applications because ultimately you'll stick with what has worked for you for years and has put food on your table. I think developers should keep an open mind and use the skillsets of the team they have. Working in a heterogenous environment with 3rd party vendors, mainframe, and different dbs would necessitate a middle tier. Using a single database with a small application, you can get away with skipping the middle tier, and a lot of companies do this. If your programmers are experienced with SQL, use that. If you've got a bunch of kids fresh out of college, you may want to stick with a middle tier so they can use their OO skills. It's all relative.
I just wanted to hear more discussion on it. Nothing more.
-
N tier development is the common practice of dividing your apps into layers that typically run on 2 or more tiers. Traditionally, these tiers are presentation - business layer - data layer. Where you basically wind up with a gui or guis that use business objects in the business layer to do things (usually involving the data layer -- though the business logic could also use service layer for other interactions). I originally was a pretty strong believer in creating a set of business logic classes that would comprise the business layer. Basically a set of object - relational mapping classes that provided some degree of mapping from database structure to business entity. However, over the past couple of years and sets of projects, I have become more a fan of hosting business logic in the database and exposing it through stored procs. This is a semi-religious debate. I now believe that a good way to do things, especially if you do not have to support multiple database platforms, is to create your database structures and then to factor your business logic/data access into stored procs and user defined functions. Your applications then interact with a very lightweight ado.net access layer to interact with this stored proc database interface. So your *business layer* is essentially in the database. I have used this for all sorts of reasonably complex systems. I believe this is a better way to develop systems than creating a bunch of classes that map tables. I also believe it is more efficient as you can keep your logic very close to the data and only return stuff that your guis are interested in displaying. Some people argue this is less scalable and creates a bottleneck on the database. I don't buy this as you can use pooling or if you really need to, clustering to eliminate this factor. Even if you do the business layer seperately as classes/services and host them on app servers, you can wind up with a bottleneck there. Plus a bunch more code, etc to support/worry about. Some people argue that TSQL is a different skill set from what developers have. I don't buy that either. Developers (atleast smart ones) are broadening their skill sets very much. The difference between a dev and dba is not significant in many cases especially regarding table design and stored proc development (yes there are many optimizations, server admin tasks better left to a dba, I'm not dismissing that). So a decent dev should know SQL very well in addition to their app dev language/s. And lets not forget the p
Tim Kohler wrote:
Some people argue this is less scalable and creates a bottleneck on the database. I don't buy this as you can use pooling or if you really need to, clustering to eliminate this factor. Even if you do the business layer seperately as classes/services and host them on app servers, you can wind up with a bottleneck there. Plus a bunch more code, etc to support/worry about.
Most app servers are designed to use multiple process to reduce bottleneck. This is a primary reason that buisness components are stateless. One might argue that using clustering of a database to scale business components is complicating the system configuration needlessly since app servers provide that natively. Scaling is complex, there is a lot of hardware and use model issues that play into it. The stored procs might actually run faster than code in an app server if they are not overloaded (bottleneck). The main thing about performance is to NOT ASSUME! Profile and prove where the issue(s) are before changing anything. My experience watching people guess is that they are successful about 0% of the time. If Profiling proves that the stored procs are an issue and you have done a good job of developing them it should not be difficult to migrate them to business objects.
Tim Kohler wrote:
Is there really any point to building a tradional business layer?
In some cases business rules just don't fit well into stored procedures.
-
N tier development is the common practice of dividing your apps into layers that typically run on 2 or more tiers. Traditionally, these tiers are presentation - business layer - data layer. Where you basically wind up with a gui or guis that use business objects in the business layer to do things (usually involving the data layer -- though the business logic could also use service layer for other interactions). I originally was a pretty strong believer in creating a set of business logic classes that would comprise the business layer. Basically a set of object - relational mapping classes that provided some degree of mapping from database structure to business entity. However, over the past couple of years and sets of projects, I have become more a fan of hosting business logic in the database and exposing it through stored procs. This is a semi-religious debate. I now believe that a good way to do things, especially if you do not have to support multiple database platforms, is to create your database structures and then to factor your business logic/data access into stored procs and user defined functions. Your applications then interact with a very lightweight ado.net access layer to interact with this stored proc database interface. So your *business layer* is essentially in the database. I have used this for all sorts of reasonably complex systems. I believe this is a better way to develop systems than creating a bunch of classes that map tables. I also believe it is more efficient as you can keep your logic very close to the data and only return stuff that your guis are interested in displaying. Some people argue this is less scalable and creates a bottleneck on the database. I don't buy this as you can use pooling or if you really need to, clustering to eliminate this factor. Even if you do the business layer seperately as classes/services and host them on app servers, you can wind up with a bottleneck there. Plus a bunch more code, etc to support/worry about. Some people argue that TSQL is a different skill set from what developers have. I don't buy that either. Developers (atleast smart ones) are broadening their skill sets very much. The difference between a dev and dba is not significant in many cases especially regarding table design and stored proc development (yes there are many optimizations, server admin tasks better left to a dba, I'm not dismissing that). So a decent dev should know SQL very well in addition to their app dev language/s. And lets not forget the p
In My Understanding: Separating data storage and business logic isn't purely a question of coding. They often have different "character", with respect to: administration, required location, changes, security, etc. Second there are implementation questions:
Tim Kohler wrote:
pooling or if you really need to, clustering
To quote - whoever: "Now you have two problems" : you have to implement clustering and then solve your performance problem. Depending on the nature, this isn't easy.
Tim Kohler wrote:
Developers (atleast smart ones)
An implementaiton that can be maintained by two average programmers is better than one that requires an excellent programmer - because there's one 'excellent' for maybe 100 'average' available. And as you say yourself, implementing and maintaining a performant database is much more than knowing TSQL. Last not least - 3 layers is good because it's known. If someone questions a 3 tier approach, you can say "We did everything by using the modern standards" - but how do you defend against "noone does two tiers, why did you?", especially when technical arguments are taboo. I am not arguing against you technical "preference" - having everything in one place surely reduces interface friction and overall complexity. I'm just trying to point out why business might prefer the classic solution.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighist -
In My Understanding: Separating data storage and business logic isn't purely a question of coding. They often have different "character", with respect to: administration, required location, changes, security, etc. Second there are implementation questions:
Tim Kohler wrote:
pooling or if you really need to, clustering
To quote - whoever: "Now you have two problems" : you have to implement clustering and then solve your performance problem. Depending on the nature, this isn't easy.
Tim Kohler wrote:
Developers (atleast smart ones)
An implementaiton that can be maintained by two average programmers is better than one that requires an excellent programmer - because there's one 'excellent' for maybe 100 'average' available. And as you say yourself, implementing and maintaining a performant database is much more than knowing TSQL. Last not least - 3 layers is good because it's known. If someone questions a 3 tier approach, you can say "We did everything by using the modern standards" - but how do you defend against "noone does two tiers, why did you?", especially when technical arguments are taboo. I am not arguing against you technical "preference" - having everything in one place surely reduces interface friction and overall complexity. I'm just trying to point out why business might prefer the classic solution.
Some of us walk the memory lane, others plummet into a rabbit hole
Tree in C# || Fold With Us! || sighistGreat points.. thanks!