Return to Answer

It really depends on your usage of stored procedures and business requirements.

There are a number of projects that do use a three-tier architecture and depending on the nature of business requirements there might be need to shift some operations to a data tier.

Speaking about terminology, in general words these tiers described as:

• The presentation tier, or user services layer - gives a user access to the application.
• The middle tier, or business services layer - consists of business and data rules.
• The data tier, or data services layer - interacts with persistent data usually stored in a database or in permanent storage.

In usual case, for the given architecture, the middle tier or business services layer, consists of business and data rules. However, sometimes it makes big difference to shift heavy set base operations and/or data rules to be done in data tier - through set of stored procedures.

The benefits of three-tier designs are:

During an application's life cycle, the three-tier approach provides benefits such as reusability, flexibility, manageability, maintainability, and scalability. You can share and reuse the components and services you create, and you can distribute them across a network of computers as needed. You can divide large and complex projects into simpler projects and assign them to different programmers or programming teams. You can also deploy components and services on a server to help keep up with changes, and you can redeploy them as growth of the application's user base, data, and transaction volume increases.

Thus, it is really a case-base approach which has trade-offs in itself. However, Microsoft design guidelines of Three-Tier Architecture Model recommends to keep your business logic in middle-tier.

Brief Summary: It really depends on your usage of stored procedures and business requirements.

There are a number of projects that do use a three-tier architecture and depending on the nature of business requirements there might be need to shift some operations to a data tier.

Speaking about terminology, in general words these tiers described as:

• The presentation tier, or user services layer - gives a user access to the application.
• The middle tier, or business services layer - consists of business and data rules.
• The data tier, or data services layer - interacts with persistent data usually stored in a database or in permanent storage.

Usually for the given architecture, the middle tier or business services layer, consists of business and data rules. However, sometimes it makes big difference to shift heavy set base operations and/or data rules to be done in data tier - through set of stored procedures.

The benefits of three-tier designs are:

During an application's life cycle, the three-tier approach provides benefits such as reusability, flexibility, manageability, maintainability, and scalability. You can share and reuse the components and services you create, and you can distribute them across a network of computers as needed. You can divide large and complex projects into simpler projects and assign them to different programmers or programming teams. You can also deploy components and services on a server to help keep up with changes, and you can redeploy them as growth of the application's user base, data, and transaction volume increases.

Thus, it is really a case-base approach which has trade-offs in itself. However, Microsoft design guidelines of Three-Tier Architecture Model recommends to keep your business logic in middle-tier.

It all really depends on your usage of stored procedures and business requirements.

There are a number of projects that do use a three-tier architecture and depending on the nature of business requirements there might be need to shift some operations to a data tier.

Speaking about terminology, in general words these tiers described as:

• The presentation tier, or user services layer - gives a user access to the application.
• The middle tier, or business services layer - consists of business and data rules.
• The data tier, or data services layer - interacts with persistent data usually stored in a database or in permanent storage.

In usual case, for the given architecture, the middle tier or business services layer, consists of business and data rules. However, sometimes it makes big difference to shift heavy set base operations and/or data rules to be done in data tier - through set of stored procedures.

The benefits of three-tier designs are:

During an application's life cycle, the three-tier approach provides benefits such as reusability, flexibility, manageability, maintainability, and scalability. You can share and reuse the components and services you create, and you can distribute them across a network of computers as needed. You can divide large and complex projects into simpler projects and assign them to different programmers or programming teams. You can also deploy components and services on a server to help keep up with changes, and you can redeploy them as growth of the application's user base, data, and transaction volume increases.

Thus, it is really a case-base approach which has trade-offs in itself. However, Microsoft design guidelines of Three-Tier Architecture Model recommends to keep your business logic in middle-tier.

It really depends on your usage of stored procedures and business requirements.

There are a number of projects that do use a three-tier architecture and depending on the nature of business requirements there might be need to shift some operations to a data tier.

Speaking about terminology, in general words these tiers described as:

• The presentation tier, or user services layer - gives a user access to the application.
• The middle tier, or business services layer - consists of business and data rules.
• The data tier, or data services layer - interacts with persistent data usually stored in a database or in permanent storage.

In usual case, for the given architecture, the middle tier or business services layer, consists of business and data rules. However, sometimes it makes big difference to shift heavy set base operations and/or data rules to be done in data tier - through set of stored procedures.

The benefits of three-tier designs are:

During an application's life cycle, the three-tier approach provides benefits such as reusability, flexibility, manageability, maintainability, and scalability. You can share and reuse the components and services you create, and you can distribute them across a network of computers as needed. You can divide large and complex projects into simpler projects and assign them to different programmers or programming teams. You can also deploy components and services on a server to help keep up with changes, and you can redeploy them as growth of the application's user base, data, and transaction volume increases.

Thus, it is really a case-base approach which has trade-offs in itself. However, Microsoft design guidelines of Three-Tier Architecture Model recommends to keep your business logic in middle-tier.

It all really depends on your usage of stored procedures and business requirements.

There are a number of projects that do use a three-tier architecture and depending on the nature of business requirements there might be need to shift some operations to a data tier.

Speaking about terminology, in general words these tiers described as:

• The presentation tier, or user services layer - gives a user access to the application.
• The middle tier, or business services layer - consists of business and data rules.
• The data tier, or data services layer - interacts with persistent data usually stored in a database or in permanent storage.

In usual case, for the given architecture, the middle tier or business services layer, consists of business and data rules. However, sometimes it makes big difference to shift heavy set base operations and/or data rules to be done in data tier - through set of stored procedures.

Thus, it is really a case-base approach which has trade-offs in itself. However, Microsoft design guidelines of Three-Tier Architecture Model recommends to keep your business logic in middle-tier.

It all really depends on your usage of stored procedures and business requirements.

There are a number of projects that do use a three-tier architecture and depending on the nature of business requirements there might be need to shift some operations to a data tier.

Speaking about terminology, in general words these tiers described as:

• The presentation tier, or user services layer - gives a user access to the application.
• The middle tier, or business services layer - consists of business and data rules.
• The data tier, or data services layer - interacts with persistent data usually stored in a database or in permanent storage.

In usual case, for the given architecture, the middle tier or business services layer, consists of business and data rules. However, sometimes it makes big difference to shift heavy set base operations and/or data rules to be done in data tier - through set of stored procedures.

The benefits of three-tier designs are:

During an application's life cycle, the three-tier approach provides benefits such as reusability, flexibility, manageability, maintainability, and scalability. You can share and reuse the components and services you create, and you can distribute them across a network of computers as needed. You can divide large and complex projects into simpler projects and assign them to different programmers or programming teams. You can also deploy components and services on a server to help keep up with changes, and you can redeploy them as growth of the application's user base, data, and transaction volume increases.

Thus, it is really a case-base approach which has trade-offs in itself. However, Microsoft design guidelines of Three-Tier Architecture Model recommends to keep your business logic in middle-tier.