|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Is this a good application Design?Currently my application has three tiers- 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) This predominantly contains User Controls, Custom Controls and Win/Web Forms. I have one base form and I inherit from that form. All validation is done in this tier. There is zero Data Access code in this tier. This tier exclusively gets DataViews/ Arays/Lists as input. Outputs are string objects with SQL Statements or just paremeters with dataconnection key. 2. Business Layer. Currently this is just a Library residing in the same machine as Presentation layer. Eventually I plan to use WebServices if application needs physical seperation. Most of Business Logic are implemented in this layer. There is absolutely no UI code here. These are all bunch of static methods which perform CRUD functionality. All methods are atomic in nature. I dont rely on Static Variables. There is just one DatabaseGateway class which does all the functionality. 3. Data Layer. (SQL Server) I dont use stored procedures. predominantly use Views. I have been reading up on Rockford Lhotka's business objects and I just feel that his framework is unnecessarily complex. I just dont see the need to hold these intermediate Business Objects. Thanks for your responses. Your SQL should be in the Business Layer. The presentation layer should not
make or provide decisions on how data is collected ( that what tables / view or columns are used ) as that is a business rule. Show quoteHide quote "Jay Balapa" <jbal***@hotmail.com> wrote in message news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... > Hello, > > Currently my application has three tiers- > > 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) > This predominantly contains User Controls, Custom Controls and Win/Web > Forms. > I have one base form and I inherit from that form. > All validation is done in this tier. There is zero Data Access code in > this tier. This tier exclusively gets DataViews/ Arays/Lists as input. > Outputs are string objects with SQL Statements or just paremeters with > dataconnection key. > > 2. Business Layer. > Currently this is just a Library residing in the same machine as > Presentation layer. Eventually I plan to use WebServices if application > needs physical seperation. > Most of Business Logic are implemented in this layer. There is absolutely > no UI code here. > These are all bunch of static methods which perform CRUD functionality. > All methods are atomic in nature. I dont rely on Static Variables. There > is just one DatabaseGateway class which does all the functionality. > > 3. Data Layer. (SQL Server) > I dont use stored procedures. predominantly use Views. > > > I have been reading up on Rockford Lhotka's business objects and I just > feel that his framework is unnecessarily complex. I just dont see the need > to hold these intermediate Business Objects. > > > > Thanks for your responses. > > -- > Jay Balapa > Director Of Software Engineering > www.atginc.com > > > > > Josh,
Thanks for your response. SQL most of the time is in the Business layer. Sometimes I need to iterate Datarows in a Datagrid. In those cases I make that exception. -- Show quoteHide quoteJay "Josh" <s@a.com> wrote in message news:OS2sZKndFHA.3324@TK2MSFTNGP10.phx.gbl... > Your SQL should be in the Business Layer. The presentation layer should > not make or provide decisions on how data is collected ( that what tables > / view or columns are used ) as that is a business rule. > > > > "Jay Balapa" <jbal***@hotmail.com> wrote in message > news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... >> Hello, >> >> Currently my application has three tiers- >> >> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) >> This predominantly contains User Controls, Custom Controls and Win/Web >> Forms. >> I have one base form and I inherit from that form. >> All validation is done in this tier. There is zero Data Access code in >> this tier. This tier exclusively gets DataViews/ Arays/Lists as input. >> Outputs are string objects with SQL Statements or just paremeters with >> dataconnection key. >> >> 2. Business Layer. >> Currently this is just a Library residing in the same machine as >> Presentation layer. Eventually I plan to use WebServices if application >> needs physical seperation. >> Most of Business Logic are implemented in this layer. There is absolutely >> no UI code here. >> These are all bunch of static methods which perform CRUD functionality. >> All methods are atomic in nature. I dont rely on Static Variables. There >> is just one DatabaseGateway class which does all the functionality. >> >> 3. Data Layer. (SQL Server) >> I dont use stored procedures. predominantly use Views. >> >> >> I have been reading up on Rockford Lhotka's business objects and I just >> feel that his framework is unnecessarily complex. I just dont see the >> need to hold these intermediate Business Objects. >> >> >> >> Thanks for your responses. >> >> -- >> Jay Balapa >> Director Of Software Engineering >> www.atginc.com >> >> >> >> >> > > Keeping the layers truely seperate is difficult. I would suggest that even
if you have to itereate through a result set the SQL should be in the Business Layer, pass your filter criteria to the business layer. Show quoteHide quote "Jay Balapa" <jbal***@hotmail.com> wrote in message news:eDFAgNndFHA.228@TK2MSFTNGP12.phx.gbl... > Josh, > > Thanks for your response. > > SQL most of the time is in the Business layer. > > Sometimes I need to iterate Datarows in a Datagrid. In those cases I make > that exception. > > -- > Jay > > > "Josh" <s@a.com> wrote in message > news:OS2sZKndFHA.3324@TK2MSFTNGP10.phx.gbl... >> Your SQL should be in the Business Layer. The presentation layer should >> not make or provide decisions on how data is collected ( that what tables >> / view or columns are used ) as that is a business rule. >> >> >> >> "Jay Balapa" <jbal***@hotmail.com> wrote in message >> news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... >>> Hello, >>> >>> Currently my application has three tiers- >>> >>> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) >>> This predominantly contains User Controls, Custom Controls and Win/Web >>> Forms. >>> I have one base form and I inherit from that form. >>> All validation is done in this tier. There is zero Data Access code in >>> this tier. This tier exclusively gets DataViews/ Arays/Lists as input. >>> Outputs are string objects with SQL Statements or just paremeters with >>> dataconnection key. >>> >>> 2. Business Layer. >>> Currently this is just a Library residing in the same machine as >>> Presentation layer. Eventually I plan to use WebServices if application >>> needs physical seperation. >>> Most of Business Logic are implemented in this layer. There is >>> absolutely no UI code here. >>> These are all bunch of static methods which perform CRUD functionality. >>> All methods are atomic in nature. I dont rely on Static Variables. >>> There is just one DatabaseGateway class which does all the >>> functionality. >>> >>> 3. Data Layer. (SQL Server) >>> I dont use stored procedures. predominantly use Views. >>> >>> >>> I have been reading up on Rockford Lhotka's business objects and I just >>> feel that his framework is unnecessarily complex. I just dont see the >>> need to hold these intermediate Business Objects. >>> >>> >>> >>> Thanks for your responses. >>> >>> -- >>> Jay Balapa >>> Director Of Software Engineering >>> www.atginc.com >>> >>> >>> >>> >>> >> >> > > I am not sure what are you getting to by insisting on moving the SQL to the
business layer. It looks to me like insisting on the dotnet framework to belong to one layer only. A database consists of tables, view, stored procedures, triggers etc. Tables and views belong to data layer. Stored procedures and triggers can be in either data or business layer. It won't hurt the SQL server if it will contain elements of both levels. Eliyahu Show quoteHide quote "Josh" <s@a.com> wrote in message news:uGdWlXndFHA.3488@tk2msftngp13.phx.gbl... > Keeping the layers truely seperate is difficult. I would suggest that even > if you have to itereate through a result set the SQL should be in the > Business Layer, pass your filter criteria to the business layer. > > > > > "Jay Balapa" <jbal***@hotmail.com> wrote in message > news:eDFAgNndFHA.228@TK2MSFTNGP12.phx.gbl... > > Josh, > > > > Thanks for your response. > > > > SQL most of the time is in the Business layer. > > > > Sometimes I need to iterate Datarows in a Datagrid. In those cases I make > > that exception. > > > > -- > > Jay > > > > > > "Josh" <s@a.com> wrote in message > > news:OS2sZKndFHA.3324@TK2MSFTNGP10.phx.gbl... > >> Your SQL should be in the Business Layer. The presentation layer should > >> not make or provide decisions on how data is collected ( that what tables > >> / view or columns are used ) as that is a business rule. > >> > >> > >> > >> "Jay Balapa" <jbal***@hotmail.com> wrote in message > >> news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... > >>> Hello, > >>> > >>> Currently my application has three tiers- > >>> > >>> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) > >>> This predominantly contains User Controls, Custom Controls and Win/Web > >>> Forms. > >>> I have one base form and I inherit from that form. > >>> All validation is done in this tier. There is zero Data Access code in > >>> this tier. This tier exclusively gets DataViews/ Arays/Lists as input. > >>> Outputs are string objects with SQL Statements or just paremeters with > >>> dataconnection key. > >>> > >>> 2. Business Layer. > >>> Currently this is just a Library residing in the same machine as > >>> Presentation layer. Eventually I plan to use WebServices if application > >>> needs physical seperation. > >>> Most of Business Logic are implemented in this layer. There is > >>> absolutely no UI code here. > >>> These are all bunch of static methods which perform CRUD functionality. > >>> All methods are atomic in nature. I dont rely on Static Variables. > >>> There is just one DatabaseGateway class which does all the > >>> functionality. > >>> > >>> 3. Data Layer. (SQL Server) > >>> I dont use stored procedures. predominantly use Views. > >>> > >>> > >>> I have been reading up on Rockford Lhotka's business objects and I just > >>> feel that his framework is unnecessarily complex. I just dont see the > >>> need to hold these intermediate Business Objects. > >>> > >>> > >>> > >>> Thanks for your responses. > >>> > >>> -- > >>> Jay Balapa > >>> Director Of Software Engineering > >>> www.atginc.com > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > > > For good architectures read on:
http://msdn.microsoft.com/practices/ArchDes/default.aspx Kurt Show quoteHide quote "Eliyahu Goldin" wrote: > I am not sure what are you getting to by insisting on moving the SQL to the > business layer. It looks to me like insisting on the dotnet framework to > belong to one layer only. > > A database consists of tables, view, stored procedures, triggers etc. Tables > and views belong to data layer. Stored procedures and triggers can be in > either data or business layer. It won't hurt the SQL server if it will > contain elements of both levels. > > Eliyahu > > "Josh" <s@a.com> wrote in message > news:uGdWlXndFHA.3488@tk2msftngp13.phx.gbl... > > Keeping the layers truely seperate is difficult. I would suggest that > even > > if you have to itereate through a result set the SQL should be in the > > Business Layer, pass your filter criteria to the business layer. > > > > > > > > > > "Jay Balapa" <jbal***@hotmail.com> wrote in message > > news:eDFAgNndFHA.228@TK2MSFTNGP12.phx.gbl... > > > Josh, > > > > > > Thanks for your response. > > > > > > SQL most of the time is in the Business layer. > > > > > > Sometimes I need to iterate Datarows in a Datagrid. In those cases I > make > > > that exception. > > > > > > -- > > > Jay > > > > > > > > > "Josh" <s@a.com> wrote in message > > > news:OS2sZKndFHA.3324@TK2MSFTNGP10.phx.gbl... > > >> Your SQL should be in the Business Layer. The presentation layer > should > > >> not make or provide decisions on how data is collected ( that what > tables > > >> / view or columns are used ) as that is a business rule. > > >> > > >> > > >> > > >> "Jay Balapa" <jbal***@hotmail.com> wrote in message > > >> news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... > > >>> Hello, > > >>> > > >>> Currently my application has three tiers- > > >>> > > >>> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) > > >>> This predominantly contains User Controls, Custom Controls and > Win/Web > > >>> Forms. > > >>> I have one base form and I inherit from that form. > > >>> All validation is done in this tier. There is zero Data Access code in > > >>> this tier. This tier exclusively gets DataViews/ Arays/Lists as > input. > > >>> Outputs are string objects with SQL Statements or just paremeters with > > >>> dataconnection key. > > >>> > > >>> 2. Business Layer. > > >>> Currently this is just a Library residing in the same machine as > > >>> Presentation layer. Eventually I plan to use WebServices if > application > > >>> needs physical seperation. > > >>> Most of Business Logic are implemented in this layer. There is > > >>> absolutely no UI code here. > > >>> These are all bunch of static methods which perform CRUD > functionality. > > >>> All methods are atomic in nature. I dont rely on Static Variables. > > >>> There is just one DatabaseGateway class which does all the > > >>> functionality. > > >>> > > >>> 3. Data Layer. (SQL Server) > > >>> I dont use stored procedures. predominantly use Views. > > >>> > > >>> > > >>> I have been reading up on Rockford Lhotka's business objects and I > just > > >>> feel that his framework is unnecessarily complex. I just dont see the > > >>> need to hold these intermediate Business Objects. > > >>> > > >>> > > >>> > > >>> Thanks for your responses. > > >>> > > >>> -- > > >>> Jay Balapa > > >>> Director Of Software Engineering > > >>> www.atginc.com > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > > > Datasets are not SQL...
So if you need to iterate through dataset objects, that just fine. But don't pass things like "SELECT * FROM Customers WHERE CustomerId = 1" from the presentation layer into the business logic. Instead you should do the following: DataSet customerData = bll.GetCustomer(1); in the presentation layer -- Show quoteHide quoteBest regards, WillemM "Eliyahu Goldin" wrote: > I am not sure what are you getting to by insisting on moving the SQL to the > business layer. It looks to me like insisting on the dotnet framework to > belong to one layer only. > > A database consists of tables, view, stored procedures, triggers etc. Tables > and views belong to data layer. Stored procedures and triggers can be in > either data or business layer. It won't hurt the SQL server if it will > contain elements of both levels. > > Eliyahu > > "Josh" <s@a.com> wrote in message > news:uGdWlXndFHA.3488@tk2msftngp13.phx.gbl... > > Keeping the layers truely seperate is difficult. I would suggest that > even > > if you have to itereate through a result set the SQL should be in the > > Business Layer, pass your filter criteria to the business layer. > > > > > > > > > > "Jay Balapa" <jbal***@hotmail.com> wrote in message > > news:eDFAgNndFHA.228@TK2MSFTNGP12.phx.gbl... > > > Josh, > > > > > > Thanks for your response. > > > > > > SQL most of the time is in the Business layer. > > > > > > Sometimes I need to iterate Datarows in a Datagrid. In those cases I > make > > > that exception. > > > > > > -- > > > Jay > > > > > > > > > "Josh" <s@a.com> wrote in message > > > news:OS2sZKndFHA.3324@TK2MSFTNGP10.phx.gbl... > > >> Your SQL should be in the Business Layer. The presentation layer > should > > >> not make or provide decisions on how data is collected ( that what > tables > > >> / view or columns are used ) as that is a business rule. > > >> > > >> > > >> > > >> "Jay Balapa" <jbal***@hotmail.com> wrote in message > > >> news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... > > >>> Hello, > > >>> > > >>> Currently my application has three tiers- > > >>> > > >>> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) > > >>> This predominantly contains User Controls, Custom Controls and > Win/Web > > >>> Forms. > > >>> I have one base form and I inherit from that form. > > >>> All validation is done in this tier. There is zero Data Access code in > > >>> this tier. This tier exclusively gets DataViews/ Arays/Lists as > input. > > >>> Outputs are string objects with SQL Statements or just paremeters with > > >>> dataconnection key. > > >>> > > >>> 2. Business Layer. > > >>> Currently this is just a Library residing in the same machine as > > >>> Presentation layer. Eventually I plan to use WebServices if > application > > >>> needs physical seperation. > > >>> Most of Business Logic are implemented in this layer. There is > > >>> absolutely no UI code here. > > >>> These are all bunch of static methods which perform CRUD > functionality. > > >>> All methods are atomic in nature. I dont rely on Static Variables. > > >>> There is just one DatabaseGateway class which does all the > > >>> functionality. > > >>> > > >>> 3. Data Layer. (SQL Server) > > >>> I dont use stored procedures. predominantly use Views. > > >>> > > >>> > > >>> I have been reading up on Rockford Lhotka's business objects and I > just > > >>> feel that his framework is unnecessarily complex. I just dont see the > > >>> need to hold these intermediate Business Objects. > > >>> > > >>> > > >>> > > >>> Thanks for your responses. > > >>> > > >>> -- > > >>> Jay Balapa > > >>> Director Of Software Engineering > > >>> www.atginc.com > > >>> > > >>> > > >>> > > >>> > > >>> > > >> > > >> > > > > > > > > > > > > > I wasn't aware that putting SQL in the business layer was a best practice. I
use SQL Server 2000 with stored procedures and my data layer accesses those stored procedures. In the business layer, I have logical business objects with properties and methods. The purpose of having a seperate data layer is so that if your data source changes (for example: moving from SQL Server to MySQL) then you only have to modify the data layer. The presentation and business layers would be unaffected. Show quoteHide quote "Josh" <s@a.com> wrote in message news:OS2sZKndFHA.3324@TK2MSFTNGP10.phx.gbl... > Your SQL should be in the Business Layer. The presentation layer should > not make or provide decisions on how data is collected ( that what tables > / view or columns are used ) as that is a business rule. > > > > "Jay Balapa" <jbal***@hotmail.com> wrote in message > news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... >> Hello, >> >> Currently my application has three tiers- >> >> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) >> This predominantly contains User Controls, Custom Controls and Win/Web >> Forms. >> I have one base form and I inherit from that form. >> All validation is done in this tier. There is zero Data Access code in >> this tier. This tier exclusively gets DataViews/ Arays/Lists as input. >> Outputs are string objects with SQL Statements or just paremeters with >> dataconnection key. >> >> 2. Business Layer. >> Currently this is just a Library residing in the same machine as >> Presentation layer. Eventually I plan to use WebServices if application >> needs physical seperation. >> Most of Business Logic are implemented in this layer. There is absolutely >> no UI code here. >> These are all bunch of static methods which perform CRUD functionality. >> All methods are atomic in nature. I dont rely on Static Variables. There >> is just one DatabaseGateway class which does all the functionality. >> >> 3. Data Layer. (SQL Server) >> I dont use stored procedures. predominantly use Views. >> >> >> I have been reading up on Rockford Lhotka's business objects and I just >> feel that his framework is unnecessarily complex. I just dont see the >> need to hold these intermediate Business Objects. >> >> >> >> Thanks for your responses. >> >> -- >> Jay Balapa >> Director Of Software Engineering >> www.atginc.com >> >> >> >> >> > > "Kim Quigley" <kimquig***@hotmail.com> wrote in There are opposing schools of thought here. You will find advice telling you both ways, and some news:#n#QjXndFHA.4040@TK2MSFTNGP14.phx.gbl: > I wasn't aware that putting SQL in the business layer was a best > practice. I use SQL Server 2000 with stored procedures and my data > layer accesses those stored procedures. In the business layer, I have saying to mix it. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu I'm only starting on Lhotka's book (which Jay here mentions), but I
think the author recommends putting the data access in with the Business Objects, but only as static CRUD methods. Then, the assemblies are duplicated on the three "internal" layers (Presentation, Business, Data Access). Unknown whether it is a best practice or not, however it allows the actual "instantiatable" BOs to be fully black-box, while still allowing the data access code full access to the BO's internals ... at least how I'm reading it. So far (about 80 pages in), the book is quite good. Sometimes it is the best practice. You can change from one platform to
another without affecting the business logic implemented in stored procedures. Eliyahu Show quoteHide quote "Kim Quigley" <kimquig***@hotmail.com> wrote in message news:%23n%23QjXndFHA.4040@TK2MSFTNGP14.phx.gbl... > I wasn't aware that putting SQL in the business layer was a best practice. I > use SQL Server 2000 with stored procedures and my data layer accesses those > stored procedures. In the business layer, I have logical business objects > with properties and methods. The purpose of having a seperate data layer is > so that if your data source changes (for example: moving from SQL Server to > MySQL) then you only have to modify the data layer. The presentation and > business layers would be unaffected. > > > "Josh" <s@a.com> wrote in message > news:OS2sZKndFHA.3324@TK2MSFTNGP10.phx.gbl... > > Your SQL should be in the Business Layer. The presentation layer should > > not make or provide decisions on how data is collected ( that what tables > > / view or columns are used ) as that is a business rule. > > > > > > > > "Jay Balapa" <jbal***@hotmail.com> wrote in message > > news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... > >> Hello, > >> > >> Currently my application has three tiers- > >> > >> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) > >> This predominantly contains User Controls, Custom Controls and Win/Web > >> Forms. > >> I have one base form and I inherit from that form. > >> All validation is done in this tier. There is zero Data Access code in > >> this tier. This tier exclusively gets DataViews/ Arays/Lists as input. > >> Outputs are string objects with SQL Statements or just paremeters with > >> dataconnection key. > >> > >> 2. Business Layer. > >> Currently this is just a Library residing in the same machine as > >> Presentation layer. Eventually I plan to use WebServices if application > >> needs physical seperation. > >> Most of Business Logic are implemented in this layer. There is absolutely > >> no UI code here. > >> These are all bunch of static methods which perform CRUD functionality. > >> All methods are atomic in nature. I dont rely on Static Variables. There > >> is just one DatabaseGateway class which does all the functionality. > >> > >> 3. Data Layer. (SQL Server) > >> I dont use stored procedures. predominantly use Views. > >> > >> > >> I have been reading up on Rockford Lhotka's business objects and I just > >> feel that his framework is unnecessarily complex. I just dont see the > >> need to hold these intermediate Business Objects. > >> > >> > >> > >> Thanks for your responses. > >> > >> -- > >> Jay Balapa > >> Director Of Software Engineering > >> www.atginc.com > >> > >> > >> > >> > >> > > > > > > Hi all;
Three tier architecture is very use ful for distributed application; You can do one thing make some common classes for common functions and use sqlhelper class as a DAL (Data Access Layer); dont customize sqlhelper class becauase this can be use for all applications. you can also customize your shared functions and pass sql statement as string and can pass perameter according to condition; but you should use stored procedure; thankx Show quoteHide quote "Eliyahu Goldin" wrote: > Sometimes it is the best practice. You can change from one platform to > another without affecting the business logic implemented in stored > procedures. > > Eliyahu > > "Kim Quigley" <kimquig***@hotmail.com> wrote in message > news:%23n%23QjXndFHA.4040@TK2MSFTNGP14.phx.gbl... > > I wasn't aware that putting SQL in the business layer was a best practice. > I > > use SQL Server 2000 with stored procedures and my data layer accesses > those > > stored procedures. In the business layer, I have logical business objects > > with properties and methods. The purpose of having a seperate data layer > is > > so that if your data source changes (for example: moving from SQL Server > to > > MySQL) then you only have to modify the data layer. The presentation and > > business layers would be unaffected. > > > > > > "Josh" <s@a.com> wrote in message > > news:OS2sZKndFHA.3324@TK2MSFTNGP10.phx.gbl... > > > Your SQL should be in the Business Layer. The presentation layer should > > > not make or provide decisions on how data is collected ( that what > tables > > > / view or columns are used ) as that is a business rule. > > > > > > > > > > > > "Jay Balapa" <jbal***@hotmail.com> wrote in message > > > news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... > > >> Hello, > > >> > > >> Currently my application has three tiers- > > >> > > >> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) > > >> This predominantly contains User Controls, Custom Controls and Win/Web > > >> Forms. > > >> I have one base form and I inherit from that form. > > >> All validation is done in this tier. There is zero Data Access code in > > >> this tier. This tier exclusively gets DataViews/ Arays/Lists as input. > > >> Outputs are string objects with SQL Statements or just paremeters with > > >> dataconnection key. > > >> > > >> 2. Business Layer. > > >> Currently this is just a Library residing in the same machine as > > >> Presentation layer. Eventually I plan to use WebServices if application > > >> needs physical seperation. > > >> Most of Business Logic are implemented in this layer. There is > absolutely > > >> no UI code here. > > >> These are all bunch of static methods which perform CRUD functionality. > > >> All methods are atomic in nature. I dont rely on Static Variables. > There > > >> is just one DatabaseGateway class which does all the functionality. > > >> > > >> 3. Data Layer. (SQL Server) > > >> I dont use stored procedures. predominantly use Views. > > >> > > >> > > >> I have been reading up on Rockford Lhotka's business objects and I just > > >> feel that his framework is unnecessarily complex. I just dont see the > > >> need to hold these intermediate Business Objects. > > >> > > >> > > >> > > >> Thanks for your responses. > > >> > > >> -- > > >> Jay Balapa > > >> Director Of Software Engineering > > >> www.atginc.com > > >> > > >> > > >> > > >> > > >> > > > > > > > > > > > > > Josh wrote:
> Your SQL should be in the Business Layer. The presentation layer SQL belongs in the Data Access Layer, not in the Business Layer. Why> should not make or provide decisions on how data is collected ( that > what tables / view or columns are used ) as that is a business rule. tie the business logic to any specific persistence mechanism? Cheers, If you want to do away with the complexity of the business objects, then
consider moving this business logic to the database as stored procedures and triggers. Show quoteHide quote "Jay Balapa" <jbal***@hotmail.com> wrote in message news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... > Hello, > > Currently my application has three tiers- > > 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) > This predominantly contains User Controls, Custom Controls and Win/Web > Forms. > I have one base form and I inherit from that form. > All validation is done in this tier. There is zero Data Access code in this > tier. This tier exclusively gets DataViews/ Arays/Lists as input. Outputs > are string objects with SQL Statements or just paremeters with > dataconnection key. > > 2. Business Layer. > Currently this is just a Library residing in the same machine as > Presentation layer. Eventually I plan to use WebServices if application > needs physical seperation. > Most of Business Logic are implemented in this layer. There is absolutely no > UI code here. > These are all bunch of static methods which perform CRUD functionality. > All methods are atomic in nature. I dont rely on Static Variables. There is > just one DatabaseGateway class which does all the functionality. > > 3. Data Layer. (SQL Server) > I dont use stored procedures. predominantly use Views. > > > I have been reading up on Rockford Lhotka's business objects and I just feel > that his framework is unnecessarily complex. I just dont see the need to > hold these intermediate Business Objects. > > > > Thanks for your responses. > > -- > Jay Balapa > Director Of Software Engineering > www.atginc.com > > > > > "bradley" <some***@microsoft.com> wrote in There are of course many schools of thought, but personally I would never recommend that. If news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: > If you want to do away with the complexity of the business objects, > then consider moving this business logic to the database as stored > procedures and triggers. you want my views as to why, you can read the link that I just posted. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka
Kudzu <c***@hower.org> writes >"bradley" <some***@microsoft.com> wrote in Agree. For one thing, TSQL is a horrible language to do anything >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: >> If you want to do away with the complexity of the business objects, >> then consider moving this business logic to the database as stored >> procedures and triggers. > >There are of course many schools of thought, but personally I would >never recommend that. If >you want my views as to why, you can read the link that I just posted. non-trivial in. -- Steve Walker Steve Walker <st***@otolith.demon.co.uk> wrote in
news:IvjyI53BeDuCFwwB@otolith.demon.co.uk: Which is one of the many points I point to in the article (or PL/SQL, or whatever)> Agree. For one thing, TSQL is a horrible language to do anything > non-trivial in. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu T-SQL is an excellent language for implementing business logic that is tied
closely to the database model or database processing. For example, imposing data constraints or referencing a set of parameters against a lookup table and returning a value. Of course, it helps is the developer is at least an intermediate level SQL programmer and familiar with sub-queries, complex joins, conditional grouping and where clauses, etc. Show quoteHide quote "Steve Walker" <st***@otolith.demon.co.uk> wrote in message news:IvjyI53BeDuCFwwB@otolith.demon.co.uk... > In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka > Kudzu <c***@hower.org> writes > >"bradley" <some***@microsoft.com> wrote in > >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: > >> If you want to do away with the complexity of the business objects, > >> then consider moving this business logic to the database as stored > >> procedures and triggers. > > > >There are of course many schools of thought, but personally I would > >never recommend that. If > >you want my views as to why, you can read the link that I just posted. > > Agree. For one thing, TSQL is a horrible language to do anything > non-trivial in. > > -- > Steve Walker "bradley" <some***@microsoft.com> wrote in I dont think you will find many that agree with you. C#, Java, anything is better at business logic.news:OXd2C0ndFHA.2500@TK2MSFTNGP10.phx.gbl: > T-SQL is an excellent language for implementing business logic that is > tied closely to the database model or database processing. For > example, imposing data constraints or referencing a set of parameters Data level storage constraints are not business logic.> against a lookup table and returning a value. Of course, it helps is Data lookups are not business logic.-- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu > Data lookups are not business logic. It can be if the business logic is implemented as meta data tables ratherthan hard coded conditional branching and looping. "Chad Z. Hower aka Kudzu" <c***@hower.org> wrote in message better at business logic.news:Xns967CC7004D8B6cpubhowerorg@127.0.0.1... > "bradley" <some***@microsoft.com> wrote in > news:OXd2C0ndFHA.2500@TK2MSFTNGP10.phx.gbl: > > T-SQL is an excellent language for implementing business logic that is > > tied closely to the database model or database processing. For > > I dont think you will find many that agree with you. C#, Java, anything is Show quoteHide quote > > > example, imposing data constraints or referencing a set of parameters > > Data level storage constraints are not business logic. > > > against a lookup table and returning a value. Of course, it helps is > > Data lookups are not business logic. > > > > -- > Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ > "Programming is an art form that fights back" > > Blog: http://blogs.atozed.com/kudzu "bradley" <some***@microsoft.com> wrote in Yes, in that case it could be. In such cases I would put in the middle tier, not the database.news:#oW#NFodFHA.2212@TK2MSFTNGP14.phx.gbl: >> Data lookups are not business logic. > > It can be if the business logic is implemented as meta data tables > rather than hard coded conditional branching and looping. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu Steve,
> T-SQL is an excellent language for implementing business logic that is Not better than English, what is called by non native English speakers often > tied > closely to the database model or database processing. For example, > imposing > data constraints or referencing a set of parameters against a lookup table > and returning a value. Of course, it helps is the developer is at least an > intermediate level SQL programmer and familiar with sub-queries, complex > joins, conditional grouping and where clauses, etc. > a very poor language when it comes to symantics. Than it is in my opinion even English with USA slang and therefore even worse. Just my thought about it. Cor In message <OXd2C0ndFHA.2***@TK2MSFTNGP10.phx.gbl>, bradley
<some***@microsoft.com> writes Show quoteHide quote > Speaking personally, I'm familiar with all of those constructs. The fact > >"Steve Walker" <st***@otolith.demon.co.uk> wrote in message >news:IvjyI53BeDuCFwwB@otolith.demon.co.uk... >> In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka >> Kudzu <c***@hower.org> writes >> >"bradley" <some***@microsoft.com> wrote in >> >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: >> >> If you want to do away with the complexity of the business objects, >> >> then consider moving this business logic to the database as stored >> >> procedures and triggers. >> > >> >There are of course many schools of thought, but personally I would >> >never recommend that. If >> >you want my views as to why, you can read the link that I just posted. >> >> Agree. For one thing, TSQL is a horrible language to do anything >> non-trivial in. >T-SQL is an excellent language for implementing business logic that is tied >closely to the database model or database processing. For example, imposing >data constraints or referencing a set of parameters against a lookup table >and returning a value. Of course, it helps is the developer is at least an >intermediate level SQL programmer and familiar with sub-queries, complex >joins, conditional grouping and where clauses, etc. that I can program competently in a language doesn't change my opinion of whether or not it is horrible. TSQL is horrible. It's BASIC with support for set-based operations and a slightly uglier procedural syntax. I'm not saying it isn't useful. It is immensely so. I'm saying I dislike it, and were it not an absolute necessity of my professional life, I'd be happy never to write another line of it. While I'm being rude about other people's pet languages, by the way, the same goes for XSLT. And yes, I'm reasonably competent in that too. -- Steve Walker With SQL Server 2005 you can write stored procedures etc. in c#.
Eliyahu Show quoteHide quote "Steve Walker" <st***@otolith.demon.co.uk> wrote in message news:IvjyI53BeDuCFwwB@otolith.demon.co.uk... > In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka > Kudzu <c***@hower.org> writes > >"bradley" <some***@microsoft.com> wrote in > >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: > >> If you want to do away with the complexity of the business objects, > >> then consider moving this business logic to the database as stored > >> procedures and triggers. > > > >There are of course many schools of thought, but personally I would > >never recommend that. If > >you want my views as to why, you can read the link that I just posted. > > Agree. For one thing, TSQL is a horrible language to do anything > non-trivial in. > > -- > Steve Walker "Eliyahu Goldin" <removemeegol***@monarchmed.com> wrote in news:#LsxRqndFHA.2076 @TK2MSFTNGP15.phx.gbl:> With SQL Server 2005 you can write stored procedures etc. in c#. Not quite... You can make calls to .NET procedures FROM STored procedures... But even then its not a good idea in most cases to put your logic in SPs. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu In message <#LsxRqndFHA.2***@TK2MSFTNGP15.phx.gbl>, Eliyahu Goldin
<removemeegol***@monarchmed.com> writes Show quoteHide quote >"Steve Walker" <st***@otolith.demon.co.uk> wrote in message Not terribly portable though, is it?>news:IvjyI53BeDuCFwwB@otolith.demon.co.uk... >> In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka >> Kudzu <c***@hower.org> writes >> >"bradley" <some***@microsoft.com> wrote in >> >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: >> >> If you want to do away with the complexity of the business objects, >> >> then consider moving this business logic to the database as stored >> >> procedures and triggers. >> >There are of course many schools of thought, but personally I would >> >never recommend that. If >> >you want my views as to why, you can read the link that I just posted. >> Agree. For one thing, TSQL is a horrible language to do anything >> non-trivial in. >With SQL Server 2005 you can write stored procedures etc. in c#. -- Steve Walker Make your mind. Horrible language vs not terribly portable.
Eliyahu Show quoteHide quote "Steve Walker" <st***@otolith.demon.co.uk> wrote in message news:ysAM4J6N4DuCFw2E@otolith.demon.co.uk... > In message <#LsxRqndFHA.2***@TK2MSFTNGP15.phx.gbl>, Eliyahu Goldin > <removemeegol***@monarchmed.com> writes > >"Steve Walker" <st***@otolith.demon.co.uk> wrote in message > >news:IvjyI53BeDuCFwwB@otolith.demon.co.uk... > >> In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka > >> Kudzu <c***@hower.org> writes > >> >"bradley" <some***@microsoft.com> wrote in > >> >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: > > >> >> If you want to do away with the complexity of the business objects, > >> >> then consider moving this business logic to the database as stored > >> >> procedures and triggers. > > >> >There are of course many schools of thought, but personally I would > >> >never recommend that. If > >> >you want my views as to why, you can read the link that I just posted. > > >> Agree. For one thing, TSQL is a horrible language to do anything > >> non-trivial in. > > >With SQL Server 2005 you can write stored procedures etc. in c#. > > Not terribly portable though, is it? > > -- > Steve Walker In message <Oz5lECodFHA.***@TK2MSFTNGP15.phx.gbl>, Eliyahu Goldin
<removemeegol***@monarchmed.com> writes Show quoteHide quote >"Steve Walker" <st***@otolith.demon.co.uk> wrote in message Using C# from within the database is not terribly portable between >news:ysAM4J6N4DuCFw2E@otolith.demon.co.uk... >> In message <#LsxRqndFHA.2***@TK2MSFTNGP15.phx.gbl>, Eliyahu Goldin >> <removemeegol***@monarchmed.com> writes >> >"Steve Walker" <st***@otolith.demon.co.uk> wrote in message >> >news:IvjyI53BeDuCFwwB@otolith.demon.co.uk... >> >> In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka >> >> Kudzu <c***@hower.org> writes >> >> >"bradley" <some***@microsoft.com> wrote in >> >> >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: >> >> >> >> If you want to do away with the complexity of the business objects, >> >> >> then consider moving this business logic to the database as stored >> >> >> procedures and triggers. >> >> >> >There are of course many schools of thought, but personally I would >> >> >never recommend that. If >> >> >you want my views as to why, you can read the link that I just posted. >> >> >> Agree. For one thing, TSQL is a horrible language to do anything >> >> non-trivial in. >> >> >With SQL Server 2005 you can write stored procedures etc. in c#. >> >> Not terribly portable though, is it? >Make your mind. Horrible language vs not terribly portable. databases. Implementing a tiered design with simple stored procedures gives you more options and allows you to do what SQL is good at in SQL and what object oriented languages are good at in object orientated languages. If presentation, domain model, data access and database logic (i.e. stored procedures)are all distinct tiers it's relatively easy to substitute a different platform for any one of them. If the stored procedures are relatively simple CRUD affairs, you will even be able to migrate to a platform which doesn't support stored procedures with relative ease. -- Steve Walker Steve Walker <st***@otolith.demon.co.uk> wrote in
news:TXS0W9HGEHuCFwxK@otolith.demon.co.uk: Spot on.> Using C# from within the database is not terribly portable between > databases. Implementing a tiered design with simple stored procedures > gives you more options and allows you to do what SQL is good at in SQL > and what object oriented languages are good at in object orientated > languages. If presentation, domain model, data access and database > logic (i.e. stored procedures)are all distinct tiers it's relatively > easy to substitute a different platform for any one of them. If the > stored procedures are relatively simple CRUD affairs, you will even be > able to migrate to a platform which doesn't support stored procedures > with relative ease. In fact, you can even see performance benefits from this approach, as well as more scalable deployments. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu Look out! The barbarians are at the gate.
Show quoteHide quote "Eliyahu Goldin" <removemeegol***@monarchmed.com> wrote in message news:%23LsxRqndFHA.2076@TK2MSFTNGP15.phx.gbl... > With SQL Server 2005 you can write stored procedures etc. in c#. > > Eliyahu > > "Steve Walker" <st***@otolith.demon.co.uk> wrote in message > news:IvjyI53BeDuCFwwB@otolith.demon.co.uk... > > In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka > > Kudzu <c***@hower.org> writes > > >"bradley" <some***@microsoft.com> wrote in > > >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: > > >> If you want to do away with the complexity of the business objects, > > >> then consider moving this business logic to the database as stored > > >> procedures and triggers. > > > > > >There are of course many schools of thought, but personally I would > > >never recommend that. If > > >you want my views as to why, you can read the link that I just posted. > > > > Agree. For one thing, TSQL is a horrible language to do anything > > non-trivial in. > > > > -- > > Steve Walker > > What? I would get your facts straight before advising people to simply
depend on C# for Stored Procedure coding. While it's entirely possible to write stored procedures and other server-side executables in CLR languages (including C# and VB.NET), it's not always (and not even usually) a good idea to do so. CLR code execution should be reserved for a few specific cases where CPU-intensive operations or those jobs that TSQL was never designed to handle. -- Show quoteHide quote____________________________________ William (Bill) Vaughn Author, Mentor, Consultant Microsoft MVP www.betav.com/blog/billva www.betav.com www.sqlreportingservices.net Please reply only to the newsgroup so that others can benefit. This posting is provided "AS IS" with no warranties, and confers no rights. __________________________________ "Eliyahu Goldin" <removemeegol***@monarchmed.com> wrote in message news:%23LsxRqndFHA.2076@TK2MSFTNGP15.phx.gbl... > With SQL Server 2005 you can write stored procedures etc. in c#. > > Eliyahu > > "Steve Walker" <st***@otolith.demon.co.uk> wrote in message > news:IvjyI53BeDuCFwwB@otolith.demon.co.uk... >> In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka >> Kudzu <c***@hower.org> writes >> >"bradley" <some***@microsoft.com> wrote in >> >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: >> >> If you want to do away with the complexity of the business objects, >> >> then consider moving this business logic to the database as stored >> >> procedures and triggers. >> > >> >There are of course many schools of thought, but personally I would >> >never recommend that. If >> >you want my views as to why, you can read the link that I just posted. >> >> Agree. For one thing, TSQL is a horrible language to do anything >> non-trivial in. >> >> -- >> Steve Walker > > "William \(Bill\) Vaughn" <billvaNoSpam@betav.com> wrote in For code that exists on the database server, I agree. Im excited about where MS is going with this, but the news:uDCovG2dFHA.3184@TK2MSFTNGP15.phx.gbl: > What? I would get your facts straight before advising people to simply > depend on C# for Stored Procedure coding. While it's entirely possible > to write stored procedures and other server-side executables in CLR > languages (including C# and VB.NET), it's not always (and not even > usually) a good idea to do so. CLR code execution should be reserved > for a few specific cases where CPU-intensive operations or those jobs > that TSQL was never designed to handle. first generation of CLR on the DB I think is going to cause more problems as its not "complete" yet as to where it will eventually go and be really useful, and in the interim users wont know the proper roles and will abuse it. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu Where did you find in my post any advice for anything? You yourself write
"it's entirely possible to write stored procedures and other server-side executables in CLR languages (including C# and VB.NET)". That's what I have said too, nothing more. Eliyahu Show quoteHide quote "William (Bill) Vaughn" <billvaNoSpam@betav.com> wrote in message news:uDCovG2dFHA.3184@TK2MSFTNGP15.phx.gbl... > What? I would get your facts straight before advising people to simply > depend on C# for Stored Procedure coding. While it's entirely possible to > write stored procedures and other server-side executables in CLR languages > (including C# and VB.NET), it's not always (and not even usually) a good > idea to do so. CLR code execution should be reserved for a few specific > cases where CPU-intensive operations or those jobs that TSQL was never > designed to handle. > > > -- > ____________________________________ > William (Bill) Vaughn > Author, Mentor, Consultant > Microsoft MVP > www.betav.com/blog/billva > www.betav.com > www.sqlreportingservices.net > Please reply only to the newsgroup so that others can benefit. > This posting is provided "AS IS" with no warranties, and confers no rights. > __________________________________ > > > "Eliyahu Goldin" <removemeegol***@monarchmed.com> wrote in message > news:%23LsxRqndFHA.2076@TK2MSFTNGP15.phx.gbl... > > With SQL Server 2005 you can write stored procedures etc. in c#. > > > > Eliyahu > > > > "Steve Walker" <st***@otolith.demon.co.uk> wrote in message > > news:IvjyI53BeDuCFwwB@otolith.demon.co.uk... > >> In message <Xns967CBDF9D71A6cpubhowerorg@127.0.0.1>, Chad Z. Hower aka > >> Kudzu <c***@hower.org> writes > >> >"bradley" <some***@microsoft.com> wrote in > >> >news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: > >> >> If you want to do away with the complexity of the business objects, > >> >> then consider moving this business logic to the database as stored > >> >> procedures and triggers. > >> > > >> >There are of course many schools of thought, but personally I would > >> >never recommend that. If > >> >you want my views as to why, you can read the link that I just posted. > >> > >> Agree. For one thing, TSQL is a horrible language to do anything > >> non-trivial in. > >> > >> -- > >> Steve Walker > > > > > > "Chad Z. Hower aka Kudzu" <c***@hower.org> wrote in message Chad,news:Xns967CBDF9D71A6cpubhowerorg@127.0.0.1... > "bradley" <some***@microsoft.com> wrote in > news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: >> If you want to do away with the complexity of the business objects, >> then consider moving this business logic to the database as stored >> procedures and triggers. > > There are of course many schools of thought, but personally I would never > recommend that. If > you want my views as to why, you can read the link that I just posted. > > I have to respectively disagree with you. There are several instances where the business logic should be in the stored procedures. Suppose you have a posting procedure that needs to compute the average cost of items based on thousands of invoices, then post those costs to another table. In order to do that logic in the business tier, you would have to retrieve all of the relevant data locally, crunch it, then send it back to the DB server in another form. This defeats the whole purpose of having a database server to begin with. Now you're back to the FoxPro days where the network bandwith was sucked up by thousands and thousands of rows of data being sent back and forth across the network for processing. One of the main advantages of having a database server is to let it crunch (read - perform logic) all the data and return only the much smaller result set. I'm not saying your approach is necessarily incorrect. That would work great if you were dealing with small chunks of data. But when you have to insert values into tables based on numbers computed from thousands of rows of data in other tables, I think it's best to let the DB server do all of the work for you. That way nothing has to travel across a wire. My $.02 Mike Rodriguez "Michael Rodriguez" <mike@nospamforme.com> wrote in These exceptions are rare, and if you read the URL I posted, I even covered this. These account for < news:Oeov7SqdFHA.3712@TK2MSFTNGP09.phx.gbl: > I have to respectively disagree with you. There are several instances > where the business logic should be in the stored procedures. Suppose > you have a posting procedure that needs to compute the average cost of > items based on thousands of invoices, then post those costs to another 1% of business logic, yet most systems implement often half of their business logic in the datbase. Even in this case, its a simle matter of running a grouping query, dividing and reposting. There are complex cases though beyond your example that definitely need to be in an SP, but again they are rare. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu
Show quote
Hide quote
"Chad Z. Hower aka Kudzu" <c***@hower.org> wrote in message I have to admit I have a rare application! We do accounting for restaurants news:Xns967D2B18963Ecpubhowerorg@127.0.0.1... > "Michael Rodriguez" <mike@nospamforme.com> wrote in > news:Oeov7SqdFHA.3712@TK2MSFTNGP09.phx.gbl: >> I have to respectively disagree with you. There are several instances >> where the business logic should be in the stored procedures. Suppose >> you have a posting procedure that needs to compute the average cost of >> items based on thousands of invoices, then post those costs to another > > These exceptions are rare, and if you read the URL I posted, I even > covered this. These account for < > 1% of business logic, yet most systems implement often half of their > business logic in the > datbase. > and everything is based on theoretical food costs, which involves a lot of data to compute. Many of my posting stored procedures are contain over 500+ lines of T-SQL code. As much as I would like that work done in the business layer, it just isn't practical in our case. I did like your article, though. Nice work. Mike "Michael Rodriguez" <mike@nospamforme.com> wrote in Exceptional cases do exist. :) But in most business applications such calculations that can be done news:e8FEusqdFHA.1600@tk2msftngp13.phx.gbl: > I have to admit I have a rare application! We do accounting for > restaurants and everything is based on theoretical food costs, which > involves a lot of data to compute. Many of my posting stored > procedures are contain over 500+ lines of T-SQL code. As much as I > would like that work done in the business layer, it just isn't > practical in our case. with measureable diference in performance in the SP's versus the business layer are a small amount. I dont envy the large SP's you have to maintain. I once designed a system to track trades, which we thousands per second. We had to build big calcuation and aggregation servers becuase not even the DB could keep up. > I did like your article, though. Nice work. Thanks. I hope you found something useful. Please feel free to pass it around and dont forget to vote in the bottom right. :) Its actually the first in a series of articles, so keep your eyes open. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu
Show quote
Hide quote
"Chad Z. Hower aka Kudzu" <c***@hower.org> wrote in message It's really a very fine line. If you have a system where hundreds of users news:Xns967DA0A2B3CAcpubhowerorg@127.0.0.1... > Exceptional cases do exist. :) But in most business applications such > calculations that can be done > with measureable diference in performance in the SP's versus the business > layer are a small > amount. > > I dont envy the large SP's you have to maintain. I once designed a system > to track trades, which we > thousands per second. We had to build big calcuation and aggregation > servers becuase not even the > DB could keep up. > are crunching loads of data, which poison do you pick? Do you do all the work in stored procedures (= database bottleneck), or do you send everything back to the clients and distribute the processing (= network bottleneck). We're still trying to figure it out... Mike "Michael Rodriguez" <mike@nospamforme.com> wrote in It depends on your system, and every sysetm is unique. No pattern will fit every system. What I news:#QvY17qdFHA.2776@TK2MSFTNGP10.phx.gbl: > It's really a very fine line. If you have a system where hundreds of > users are crunching loads of data, which poison do you pick? Do you > do all the work in stored procedures (= database bottleneck), or do > you send everything back to the clients and distribute the processing > (= network bottleneck). We're still trying to figure it out... presented works well in my experience in 90%+ of systems. But each developer needs to evualate the pattern and see if it is a good match for their system. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu I agree with it though, it's not the correct example.
In our case we need to pull the data from different tables, apply business logic then pull data from other tables if required and insert in to Temporary table then open cursor on Temporary table which returns data to calling application. Regards, Mahesh Show quoteHide quote "Michael Rodriguez" wrote: > "Chad Z. Hower aka Kudzu" <c***@hower.org> wrote in message > news:Xns967CBDF9D71A6cpubhowerorg@127.0.0.1... > > "bradley" <some***@microsoft.com> wrote in > > news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: > >> If you want to do away with the complexity of the business objects, > >> then consider moving this business logic to the database as stored > >> procedures and triggers. > > > > There are of course many schools of thought, but personally I would never > > recommend that. If > > you want my views as to why, you can read the link that I just posted. > > > > > > Chad, > > I have to respectively disagree with you. There are several instances where > the business logic should be in the stored procedures. Suppose you have a > posting procedure that needs to compute the average cost of items based on > thousands of invoices, then post those costs to another table. In order to > do that logic in the business tier, you would have to retrieve all of the > relevant data locally, crunch it, then send it back to the DB server in > another form. This defeats the whole purpose of having a database server to > begin with. Now you're back to the FoxPro days where the network bandwith > was sucked up by thousands and thousands of rows of data being sent back and > forth across the network for processing. One of the main advantages of > having a database server is to let it crunch (read - perform logic) all the > data and return only the much smaller result set. > > I'm not saying your approach is necessarily incorrect. That would work > great if you were dealing with small chunks of data. But when you have to > insert values into tables based on numbers computed from thousands of rows > of data in other tables, I think it's best to let the DB server do all of > the work for you. That way nothing has to travel across a wire. > > My $.02 > > Mike Rodriguez > > > =?Utf-8?B?TWFoZXNo?= <Mah***@discussions.microsoft.com> wrote in
news:904BF305-5008-4698-95D6-DE460EBFE706@microsoft.com: Which is the overwhelmingly common scenario. What I described will work very well for you.> I agree with it though, it's not the correct example. > > In our case we need to pull the data from different tables, apply > business logic then pull data from other tables if required and > insert in to Temporary table then open cursor on Temporary table which > returns data to calling application. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu I agree. I am don't believe in putting business logic inside of the
database. Business logic belongs in the Business Logic Layer (BLL). In addition, SQL commands and data access code do not belong in the BLL. A entity should never know how to persist itself in the database. This is why I am not a fan of Lhotka's CSLA framework. This breaks classic object oriented programming rules. Show quoteHide quote "Chad Z. Hower aka Kudzu" wrote: > "bradley" <some***@microsoft.com> wrote in > news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: > > If you want to do away with the complexity of the business objects, > > then consider moving this business logic to the database as stored > > procedures and triggers. > > There are of course many schools of thought, but personally I would never recommend that. If > you want my views as to why, you can read the link that I just posted. > > > -- > Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ > "Programming is an art form that fights back" > > Blog: http://blogs.atozed.com/kudzu > This has served me pretty well as a base design for
the software families I work on: -- Show quoteHide quoteRobbe Morris - 2004/2005 Microsoft MVP C# EggHeadCafe's RSS Search Engine http://www.eggheadcafe.com/articles/multisearch/default.aspx "Tony Phillips" <Tony Phill***@discussions.microsoft.com> wrote in message news:A001F690-2444-41D8-A43E-DBEDC5906F0B@microsoft.com... >I agree. I am don't believe in putting business logic inside of the > database. Business logic belongs in the Business Logic Layer (BLL). In > addition, SQL commands and data access code do not belong in the BLL. A > entity should never know how to persist itself in the database. This is > why > I am not a fan of Lhotka's CSLA framework. This breaks classic object > oriented programming rules. > > "Chad Z. Hower aka Kudzu" wrote: > >> "bradley" <some***@microsoft.com> wrote in >> news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: >> > If you want to do away with the complexity of the business objects, >> > then consider moving this business logic to the database as stored >> > procedures and triggers. >> >> There are of course many schools of thought, but personally I would never >> recommend that. If >> you want my views as to why, you can read the link that I just posted. >> >> >> -- >> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ >> "Programming is an art form that fights back" >> >> Blog: http://blogs.atozed.com/kudzu >>
http://www.eggheadcafe.com/articles/aspnet_how_to_create_object_oriented_applications.asp
--
Show quote
Hide quote
Robbe Morris - 2004/2005 Microsoft MVP C# EggHeadCafe's RSS Search Engine http://www.eggheadcafe.com/articles/multisearch/default.aspx "Tony Phillips" <Tony Phill***@discussions.microsoft.com> wrote in message
news:A001F690-2444-41D8-A43E-DBEDC5906F0B@microsoft.com... >I agree. I am don't believe in putting business logic inside of the > database. Business logic belongs in the Business Logic Layer (BLL). In > addition, SQL commands and data access code do not belong in the BLL. A > entity should never know how to persist itself in the database. This is > why > I am not a fan of Lhotka's CSLA framework. This breaks classic object > oriented programming rules. > > "Chad Z. Hower aka Kudzu" wrote: > >> "bradley" <some***@microsoft.com> wrote in >> news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: >> > If you want to do away with the complexity of the business objects, >> > then consider moving this business logic to the database as stored >> > procedures and triggers. >> >> There are of course many schools of thought, but personally I would never >> recommend that. If >> you want my views as to why, you can read the link that I just posted. >> >> >> -- >> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ >> "Programming is an art form that fights back" >> >> Blog: http://blogs.atozed.com/kudzu >> Pretty good stuff, Robbe!
-- Show quoteHide quoteKevin Spencer Microsoft MVP ..Net Developer Neither a follower nor a lender be. "Robbe Morris [C# MVP]" <i***@eggheadcafe.com> wrote in message news:OzcH74ZuFHA.3256@TK2MSFTNGP09.phx.gbl... > http://www.eggheadcafe.com/articles/aspnet_how_to_create_object_oriented_applications.asp > > -- > Robbe Morris - 2004/2005 Microsoft MVP C# > EggHeadCafe's RSS Search Engine > http://www.eggheadcafe.com/articles/multisearch/default.aspx > > > > > "Tony Phillips" <Tony Phill***@discussions.microsoft.com> wrote in message > news:A001F690-2444-41D8-A43E-DBEDC5906F0B@microsoft.com... >>I agree. I am don't believe in putting business logic inside of the >> database. Business logic belongs in the Business Logic Layer (BLL). In >> addition, SQL commands and data access code do not belong in the BLL. A >> entity should never know how to persist itself in the database. This is >> why >> I am not a fan of Lhotka's CSLA framework. This breaks classic object >> oriented programming rules. >> >> "Chad Z. Hower aka Kudzu" wrote: >> >>> "bradley" <some***@microsoft.com> wrote in >>> news:#93$ARndFHA.1456@TK2MSFTNGP15.phx.gbl: >>> > If you want to do away with the complexity of the business objects, >>> > then consider moving this business logic to the database as stored >>> > procedures and triggers. >>> >>> There are of course many schools of thought, but personally I would >>> never recommend that. If >>> you want my views as to why, you can read the link that I just posted. >>> >>> >>> -- >>> Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ >>> "Programming is an art form that fights back" >>> >>> Blog: http://blogs.atozed.com/kudzu >>> > > "=?Utf-8?B?VG9ueSBQaGlsbGlwcw==?=" <Tony
Phill***@discussions.microsoft.com> wrote in news:A001F690-2444-41D8-A43E-DBEDC5906F0B@microsoft.com: For differing views (ones I dont agree with, but you should always consider alternate views and > I agree. I am don't believe in putting business logic inside of the > database. Business logic belongs in the Business Logic Layer (BLL). > In addition, SQL commands and data access code do not belong in the > BLL. A entity should never know how to persist itself in the > database. This is why I am not a fan of Lhotka's CSLA framework. > This breaks classic object oriented programming rules. make your own choices) Subject: Re: n-Tier Business App - Complex Logic Newsgroups: microsoft.public.dotnet.distributed_apps -- Chad Z. Hower (a.k.a. Kudzu) "Programming is an art form that fights back" Stuff: http://www.KudzuWorld.com Blogs: http://www.KudzuWorld.com/blogs >>>>>>>>>>>>>>>> moving this business logic to the database as stored procedures and>>>>>>>>>>>>>>>>>>> Problem with that approach is our application will have to support ACCESS as well as SQL Server, in future we might have to deal with Oracle. We program exclusively on interfaces and not on actual SQL or OLE objects. By using simple Views we can mask the changes in underlying tables if needed. -jay Show quoteHide quote "bradley" <some***@microsoft.com> wrote in message news:%2393$ARndFHA.1456@TK2MSFTNGP15.phx.gbl... > If you want to do away with the complexity of the business objects, then > consider moving this business logic to the database as stored procedures > and > triggers. > > "Jay Balapa" <jbal***@hotmail.com> wrote in message > news:%23zUYpHndFHA.3488@tk2msftngp13.phx.gbl... >> Hello, >> >> Currently my application has three tiers- >> >> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) >> This predominantly contains User Controls, Custom Controls and Win/Web >> Forms. >> I have one base form and I inherit from that form. >> All validation is done in this tier. There is zero Data Access code in > this >> tier. This tier exclusively gets DataViews/ Arays/Lists as input. >> Outputs >> are string objects with SQL Statements or just paremeters with >> dataconnection key. >> >> 2. Business Layer. >> Currently this is just a Library residing in the same machine as >> Presentation layer. Eventually I plan to use WebServices if application >> needs physical seperation. >> Most of Business Logic are implemented in this layer. There is absolutely > no >> UI code here. >> These are all bunch of static methods which perform CRUD functionality. >> All methods are atomic in nature. I dont rely on Static Variables. There > is >> just one DatabaseGateway class which does all the functionality. >> >> 3. Data Layer. (SQL Server) >> I dont use stored procedures. predominantly use Views. >> >> >> I have been reading up on Rockford Lhotka's business objects and I just > feel >> that his framework is unnecessarily complex. I just dont see the need to >> hold these intermediate Business Objects. >> >> >> >> Thanks for your responses. >> >> -- >> Jay Balapa >> Director Of Software Engineering >> www.atginc.com >> >> >> >> >> > > "Jay Balapa" <jbal***@hotmail.com> wrote in Then you should do it as my article says.news:O$dyp8ndFHA.3376@TK2MSFTNGP10.phx.gbl: > Problem with that approach is our application will have to support > ACCESS as well as SQL Server, in future we might have to deal with > Oracle. > We program exclusively on interfaces and not on actual SQL or OLE Thats very good, but views wont do complex transforms. And the matter of views vs sps is a SQL > objects. By using simple Views we can mask the changes in underlying > tables if needed. server one, SQL Server is not efficient with views, use SP "as views" when using SQL server. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu "Jay Balapa" <jbal***@hotmail.com> wrote in
http://www.codeproject.com/useritems/DudeWheresMyBusinessLogic.asp
news:#zUYpHndFHA.3488@tk2msftngp13.phx.gbl: > Thanks for your responses. --
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu "Jay Balapa" <jbal***@hotmail.com> wrote in Views are good - BUT with SQL Server result set based stored procedures are typcially better news:#zUYpHndFHA.3488@tk2msftngp13.phx.gbl: > 3. Data Layer. (SQL Server) > I dont use stored procedures. predominantly use Views. because of SQL servers optimization techniques. Newer versions are adressing this, but as to how much I dont know yet. -- Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/ "Programming is an art form that fights back" Blog: http://blogs.atozed.com/kudzu Hi Jay,
> 1. Presentation Layer (Asp.Net / Win Forms/ Pocket PC UI.) All this looks pretty good... but...> This predominantly contains User Controls, Custom Controls and Win/Web > Forms. > I have one base form and I inherit from that form. > All validation is done in this tier. There is zero Data Access code in > this tier. This tier exclusively gets DataViews/ Arays/Lists as input. > Outputs are string objects with SQL Statements or just paremeters with This is a pretty bad idea. Your presentation objects should pass data > dataconnection key. views, data sets, lists of business objects, etc, to the business layer. The presentation layer must not know anything about the persistence mechanism. Otherwise, you end up with expensive code to maintain. > This is a structured programming approach. It is not really my style. I > 2. Business Layer. > Currently this is just a Library residing in the same machine as > Presentation layer. Eventually I plan to use WebServices if application > needs physical seperation. > Most of Business Logic are implemented in this layer. There is absolutely > no UI code here. > These are all bunch of static methods which perform CRUD functionality. > All methods are atomic in nature. I dont rely on Static Variables. There > is just one DatabaseGateway class which does all the functionality. fail to see how you can truly move business logic through a "God Class." (A God Class is an antipattern. The God Class sees everything, knows everything, and does everything. :-). This nearly always violates the Open-Closed principle and produces fragile code (usually in other layers). Handing off the difficult part to other layers because it is hard to do it in the business layer is not my first recommendation. Note that CRUD functionality is not usually the same as a business rule. In fact, I would suggest that 90% of the real business rules in your app are not related at all to CRUD functions. These are database operations. If your system is truly partitioned this way, then your business logic is in the presentation layer. > 3. Data Layer. (SQL Server) I read your subsequent posts about why you don't use stored procs. I > I dont use stored procedures. predominantly use Views. > understand and sympathize. However, typically in code, we have a Data Access Layer that hides the fact that your underlying system is a particular database. This data access layer does many of the connection and CRUD operations. If you truly want to reconsider how to partition the functionality of your system, create an idea in your head of the purpose for each layer. Write that purpose in large letters on a white board, divided into sections for each layer, and then break our the activities of your system into methods that you will implement in each layer. Write these methods under the heading. Make sure that the purpose matches the method. If the method doesn't support, defend, and make sense in light of the purpose, move it or redefine it. Your answer is your own. It is much easier to work with that way, and if it works for you, use it. Don't let an author decide for you... or a geek on a newsgroup :-). In my experience, I have found that CRUD is a feature of the data access layer. Business objects enforce business rules and nothing else. Presentation layers deal with presentation and format validation. That allows me to seperate the functions in a way that is easier to maintain. Consider reading about the "Layers" pattern in the Buschmann book on patterns. -- --- Nick Malik [Microsoft] MCSD, CFPS, Certified Scrummaster http://blogs.msdn.com/nickmalik Disclaimer: Opinions expressed in this forum are my own, and not representative of my employer. I do not answer questions on behalf of my employer. I'm just a programmer helping programmers. --  
Other interesting topics
Operator '=' on System.DateTime and System.Double
sqltransaction Trying to find ClientID of web form - Update System.InvalidOperationException: ExecuteReader from mm/dd/yyyy to yyyy/mm/dd CancelCurrentEdit doesn't OleDb: Get Properties Oracle and .NET stored procedures returning dataset... Displaying many-to-many relation data in dataGrids Trying to find ClientID of web form |
|||||||||||||||||||||||
