|
.net
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Why we need business logic layer?I don't have clear reasons why we need business logic layer and data logic
layer instead of having only data logic layer. Are there any good reasons for that? Sure, there are plenty of reasons. The most important though is that if
anything about your business logic or your data logic changes (as always happens), you can replace just one layer of code without having to disturb the other. The business layer is where your business rules are processed, the data layer is where your data manipulation is done. Separating these also adds another level of security to your applicaiton. Show quote "MS newsgroup" <k***@jeromegroup.com> wrote in message news:elfI4JHyGHA.4024@TK2MSFTNGP02.phx.gbl... >I don't have clear reasons why we need business logic layer and data logic >layer instead of having only data logic layer. > > Are there any good reasons for that? > > however,
if there is only one data access layer then, it doesn't worry about other lay automatically. and if they want security reason it is managed easily using storedprocedure easily. are there any other good reasons? Show quote "Scott M." <s-mar@nospam.nospam> wrote in message news:%2368K3QHyGHA.4984@TK2MSFTNGP05.phx.gbl... > Sure, there are plenty of reasons. The most important though is that if > anything about your business logic or your data logic changes (as always > happens), you can replace just one layer of code without having to disturb > the other. > > The business layer is where your business rules are processed, the data > layer is where your data manipulation is done. Separating these also adds > another level of security to your applicaiton. > > > "MS newsgroup" <k***@jeromegroup.com> wrote in message > news:elfI4JHyGHA.4024@TK2MSFTNGP02.phx.gbl... >>I don't have clear reasons why we need business logic layer and data logic >>layer instead of having only data logic layer. >> >> Are there any good reasons for that? >> >> > > How about reusability? The UI layer only knows about the business layer. The
business layer only knows about the data layer. Therefore, if you have another project, you can re-use the data layer in that project. Also, let's say that you have created a Windows Forms application. Now you receive a requirement that the same application must be made available via an ASP.Net web site. If you properly separate your UI layer from the business layer, you can easily re-use the same business layer with the web interface. It's partially all about dependencies. The more independent a component is, the more reusable it is. It's also about maintenance. But that's been covered before. And extensibility (as per my example). If you program for a few years, you'll figure it out all by yourself, via the school of hard knocks. Once you're tired of having to maintain, debug, and extend your own poorly-architected applications, re-inventing the same wheels over and over again, you figure this stuff out for yourself. Or you can take the easy way, and learn from those who already have the experience. -- Show quoteHTH, Kevin Spencer Microsoft MVP Chicken Salad Surgery It takes a tough man to make a tender chicken salad. "MS newsgroup" <k***@jeromegroup.com> wrote in message news:%235qhJZHyGHA.4232@TK2MSFTNGP04.phx.gbl... > however, > if there is only one data access layer then, it doesn't worry about other > lay automatically. > and if they want security reason it is managed easily using > storedprocedure easily. > > are there any other good reasons? > > > > "Scott M." <s-mar@nospam.nospam> wrote in message > news:%2368K3QHyGHA.4984@TK2MSFTNGP05.phx.gbl... >> Sure, there are plenty of reasons. The most important though is that if >> anything about your business logic or your data logic changes (as always >> happens), you can replace just one layer of code without having to >> disturb the other. >> >> The business layer is where your business rules are processed, the data >> layer is where your data manipulation is done. Separating these also >> adds another level of security to your applicaiton. >> >> >> "MS newsgroup" <k***@jeromegroup.com> wrote in message >> news:elfI4JHyGHA.4024@TK2MSFTNGP02.phx.gbl... >>>I don't have clear reasons why we need business logic layer and data >>>logic layer instead of having only data logic layer. >>> >>> Are there any good reasons for that? >>> >>> >> >> > > It doesn't matter that there is only one data access requirement. Business
logic is not the same a data logic. The business layer needn't and shouldn't know where the data resides or how to access it. By separating the layers, either layer can be reused, modified or replaced with minimal impact on the other layers. Show quote "MS newsgroup" <k***@jeromegroup.com> wrote in message news:%235qhJZHyGHA.4232@TK2MSFTNGP04.phx.gbl... > however, > if there is only one data access layer then, it doesn't worry about other > lay automatically. > and if they want security reason it is managed easily using > storedprocedure easily. > > are there any other good reasons? > > > > "Scott M." <s-mar@nospam.nospam> wrote in message > news:%2368K3QHyGHA.4984@TK2MSFTNGP05.phx.gbl... >> Sure, there are plenty of reasons. The most important though is that if >> anything about your business logic or your data logic changes (as always >> happens), you can replace just one layer of code without having to >> disturb the other. >> >> The business layer is where your business rules are processed, the data >> layer is where your data manipulation is done. Separating these also >> adds another level of security to your applicaiton. >> >> >> "MS newsgroup" <k***@jeromegroup.com> wrote in message >> news:elfI4JHyGHA.4024@TK2MSFTNGP02.phx.gbl... >>>I don't have clear reasons why we need business logic layer and data >>>logic layer instead of having only data logic layer. >>> >>> Are there any good reasons for that? >>> >>> >> >> > > On Fri, 25 Aug 2006 14:31:25 -0400, "Scott M." <s-mar@nospam.nospam> I prefer a 'translation' layer between the business and data layers.wrote: >Sure, there are plenty of reasons. The most important though is that if >anything about your business logic or your data logic changes (as always >happens), you can replace just one layer of code without having to disturb >the other. > >The business layer is where your business rules are processed, the data >layer is where your data manipulation is done. Separating these also adds >another level of security to your applicaiton. > This extra layer tends to be very thin and solves the issue of how and where data gets turned into objects and vice versa. Changes to either the business or data layer are reflected in the translation layer. The isolation becomes pretty complete, the business layer knows nothing about data objects and the data layer knows nothing about business objects. regards A.G. Well if you are building an application to track your CD collection at home
then you can do whatever you want. However, in the corporate world where you have distributed applications that are critical for performance, maintainability, and scaleability then you would want to employ a good design model for your system. Traditionally, the path is to use logical layers (sometimes they are physical separations also). You should shoot for logical partitioning (layers) and design using interfaces as a contract between layers. Doing this will make it easier to move your functionality. So, lets say you have a business component that must do some pretty hefty math and lot's of CPU power and so you want to take advantage of your corporate server that is a muscle machine with Duel Core technology and ton's of RAM for such feats. It can host your business component. However, if it was so tightly coupled with your data access component you couldn't do this, thus it is not loosely coupled and highly cohesive. If you don't apply logical layers to your application it will result in monolithic apps that are hard to maintain, make enhancements, and scale. Maintenance would become a big problem because then it would be very hard to size up the effect of any changes or enhancements you may make in one component on the other components in the app. Hope that helps. -- Show quote-Demetri "MS newsgroup" wrote: > I don't have clear reasons why we need business logic layer and data logic > layer instead of having only data logic layer. > > Are there any good reasons for that? > > > But if the data model changes, I have to change the data layer as well as
the business layer, haven't I? Which layers do you have, or what do you recommend to put in the individual layers? Jan Show quote "Demetri" <Deme***@discussions.microsoft.com> wrote in message news:AE8283FD-EF2A-4488-BDB8-541F89B9C999@microsoft.com... > Well if you are building an application to track your CD collection at > home > then you can do whatever you want. > > However, in the corporate world where you have distributed applications > that > are critical for performance, maintainability, and scaleability then you > would want to employ a good design model for your system. > > Traditionally, the path is to use logical layers (sometimes they are > physical separations also). > > You should shoot for logical partitioning (layers) and design using > interfaces as a contract between layers. Doing this will make it easier to > move your functionality. So, lets say you have a business component that > must > do some pretty hefty math and lot's of CPU power and so you want to take > advantage of your corporate server that is a muscle machine with Duel Core > technology and ton's of RAM for such feats. It can host your business > component. However, if it was so tightly coupled with your data access > component you couldn't do this, thus it is not loosely coupled and highly > cohesive. > > If you don't apply logical layers to your application it will result in > monolithic apps that are hard to maintain, make enhancements, and scale. > > Maintenance would become a big problem because then it would be very hard > to > size up the effect of any changes or enhancements you may make in one > component on the other components in the app. > > Hope that helps. > -- > -Demetri > > > "MS newsgroup" wrote: > >> I don't have clear reasons why we need business logic layer and data >> logic >> layer instead of having only data logic layer. >> >> Are there any good reasons for that? >> >> >> Well, as I said before you can use interfaces as a contract between your
components, this way if your data model changes thus it changes your data access component it still won't affect your business component. To Illustrate: Lets say you have a system that shows products you offer. You have three components: 1. Entities - Business entities component that has a class called ProductInfo. 2. IDAL - This contains an interface class called IProduct that has a GetProducts method that returns a list of ProductInfo classes from the Entities component. 3. SQLServerDAL - This contains a class called Product that inherits from IProduct thus has a method called GetProducts. 4. DALFactory - This has a class called DataAccess and has a method called CreateProduct which returns an IProduct interface. This is your data factory class. 5. BLL - This is your business logical layer and it has a class called Product, which has a method called GetProducts. The method uses the DALFactory.Access.CreateProduct method to get the appropriate data access component to use, in this case its the SQLServerDAL component. It returns a list of ProductInfo entities to the caller. In this scenario you can have your Business layer use ANY data access layer that inherits from IProduct. Therefore, if you currently use SQLServer but now have to migrate to Oracle or your column naming conventions change, or your stored procedures get renamed then your Business layer doesn't care therefore the only thing you have to re-deploy is the data access layer. You minimize regression testing, impact on other code, it is highly scaleable, among a whole host of other benefits. Hope this helps! -- Show quote-Demetri "Jan Kucera" wrote: > But if the data model changes, I have to change the data layer as well as > the business layer, haven't I? > > Which layers do you have, or what do you recommend to put in the individual > layers? > > Jan > > > "Demetri" <Deme***@discussions.microsoft.com> wrote in message > news:AE8283FD-EF2A-4488-BDB8-541F89B9C999@microsoft.com... > > Well if you are building an application to track your CD collection at > > home > > then you can do whatever you want. > > > > However, in the corporate world where you have distributed applications > > that > > are critical for performance, maintainability, and scaleability then you > > would want to employ a good design model for your system. > > > > Traditionally, the path is to use logical layers (sometimes they are > > physical separations also). > > > > You should shoot for logical partitioning (layers) and design using > > interfaces as a contract between layers. Doing this will make it easier to > > move your functionality. So, lets say you have a business component that > > must > > do some pretty hefty math and lot's of CPU power and so you want to take > > advantage of your corporate server that is a muscle machine with Duel Core > > technology and ton's of RAM for such feats. It can host your business > > component. However, if it was so tightly coupled with your data access > > component you couldn't do this, thus it is not loosely coupled and highly > > cohesive. > > > > If you don't apply logical layers to your application it will result in > > monolithic apps that are hard to maintain, make enhancements, and scale. > > > > Maintenance would become a big problem because then it would be very hard > > to > > size up the effect of any changes or enhancements you may make in one > > component on the other components in the app. > > > > Hope that helps. > > -- > > -Demetri > > > > > > "MS newsgroup" wrote: > > > >> I don't have clear reasons why we need business logic layer and data > >> logic > >> layer instead of having only data logic layer. > >> > >> Are there any good reasons for that? > >> > >> > >> > > 5 Components!!! I can architect an application but can't do math worth a
toot! :-) -- Show quote-Demetri "Demetri" wrote: > Well, as I said before you can use interfaces as a contract between your > components, this way if your data model changes thus it changes your data > access component it still won't affect your business component. > > To Illustrate: > Lets say you have a system that shows products you offer. > > You have three components: > 1. Entities - Business entities component that has a class called > ProductInfo. > 2. IDAL - This contains an interface class called IProduct that has a > GetProducts method that returns a list of ProductInfo classes from the > Entities component. > 3. SQLServerDAL - This contains a class called Product that inherits from > IProduct thus has a method called GetProducts. > 4. DALFactory - This has a class called DataAccess and has a method called > CreateProduct which returns an IProduct interface. This is your data factory > class. > 5. BLL - This is your business logical layer and it has a class called > Product, which has a method called GetProducts. The method uses the > DALFactory.Access.CreateProduct method to get the appropriate data access > component to use, in this case its the SQLServerDAL component. It returns a > list of ProductInfo entities to the caller. > > In this scenario you can have your Business layer use ANY data access layer > that inherits from IProduct. Therefore, if you currently use SQLServer but > now have to migrate to Oracle or your column naming conventions change, or > your stored procedures get renamed then your Business layer doesn't care > therefore the only thing you have to re-deploy is the data access layer. You > minimize regression testing, impact on other code, it is highly scaleable, > among a whole host of other benefits. > > Hope this helps! > > -- > -Demetri > > > "Jan Kucera" wrote: > > > But if the data model changes, I have to change the data layer as well as > > the business layer, haven't I? > > > > Which layers do you have, or what do you recommend to put in the individual > > layers? > > > > Jan > > > > > > "Demetri" <Deme***@discussions.microsoft.com> wrote in message > > news:AE8283FD-EF2A-4488-BDB8-541F89B9C999@microsoft.com... > > > Well if you are building an application to track your CD collection at > > > home > > > then you can do whatever you want. > > > > > > However, in the corporate world where you have distributed applications > > > that > > > are critical for performance, maintainability, and scaleability then you > > > would want to employ a good design model for your system. > > > > > > Traditionally, the path is to use logical layers (sometimes they are > > > physical separations also). > > > > > > You should shoot for logical partitioning (layers) and design using > > > interfaces as a contract between layers. Doing this will make it easier to > > > move your functionality. So, lets say you have a business component that > > > must > > > do some pretty hefty math and lot's of CPU power and so you want to take > > > advantage of your corporate server that is a muscle machine with Duel Core > > > technology and ton's of RAM for such feats. It can host your business > > > component. However, if it was so tightly coupled with your data access > > > component you couldn't do this, thus it is not loosely coupled and highly > > > cohesive. > > > > > > If you don't apply logical layers to your application it will result in > > > monolithic apps that are hard to maintain, make enhancements, and scale. > > > > > > Maintenance would become a big problem because then it would be very hard > > > to > > > size up the effect of any changes or enhancements you may make in one > > > component on the other components in the app. > > > > > > Hope that helps. > > > -- > > > -Demetri > > > > > > > > > "MS newsgroup" wrote: > > > > > >> I don't have clear reasons why we need business logic layer and data > > >> logic > > >> layer instead of having only data logic layer. > > >> > > >> Are there any good reasons for that? > > >> > > >> > > >> > > > > "Jan Kucera" <kuc***@lupacovka.cz> wrote in message Not necessarially. It's actually quite rare (and not a good idea) to change news:2FF1228F-68DC-4800-A665-C7AF3F238C4B@microsoft.com... > But if the data model changes, I have to change the data layer as well as > the business layer, haven't I? the database's interface (names of stored procs., table design, etc.). But it is quite common to change databases entirely. So, if the "old" database was, say, Oracle and the new one is SQL Server, your data layer would need to be re-written for different data access, but the SP names as well as input/output parameters don't neccessarially change. None of this need affect the business layer at all. > Which layers do you have, or what do you recommend to put in the It's pretty common to have (at least) a UI layer, a business layer and a > individual layers? data layer. UI layer - responsible for all aspects of the user's interface with the application. This would be the web pages of a web based application or the form or console of a client application. User input is validated here and results and errors are formatted and presented here. Business layer - business rules are processed here (i.e. functions that BEGIN the process of getting, modifying and creating customer or vendor data). Data layer - usually called by the business layer methods. This layer receives business layer data, connects to the data store and sends results back to the business layer. Show quote > > Jan > > > "Demetri" <Deme***@discussions.microsoft.com> wrote in message > news:AE8283FD-EF2A-4488-BDB8-541F89B9C999@microsoft.com... >> Well if you are building an application to track your CD collection at >> home >> then you can do whatever you want. >> >> However, in the corporate world where you have distributed applications >> that >> are critical for performance, maintainability, and scaleability then you >> would want to employ a good design model for your system. >> >> Traditionally, the path is to use logical layers (sometimes they are >> physical separations also). >> >> You should shoot for logical partitioning (layers) and design using >> interfaces as a contract between layers. Doing this will make it easier >> to >> move your functionality. So, lets say you have a business component that >> must >> do some pretty hefty math and lot's of CPU power and so you want to take >> advantage of your corporate server that is a muscle machine with Duel >> Core >> technology and ton's of RAM for such feats. It can host your business >> component. However, if it was so tightly coupled with your data access >> component you couldn't do this, thus it is not loosely coupled and highly >> cohesive. >> >> If you don't apply logical layers to your application it will result in >> monolithic apps that are hard to maintain, make enhancements, and scale. >> >> Maintenance would become a big problem because then it would be very hard >> to >> size up the effect of any changes or enhancements you may make in one >> component on the other components in the app. >> >> Hope that helps. >> -- >> -Demetri >> >> >> "MS newsgroup" wrote: >> >>> I don't have clear reasons why we need business logic layer and data >>> logic >>> layer instead of having only data logic layer. >>> >>> Are there any good reasons for that? >>> >>> >>> >
Show quote
"Scott M." <s-mar@nospam.nospam> wrote in message Actually my data layer uses DbConnection, DbCommand and others class which I news:%23i72fhJyGHA.3632@TK2MSFTNGP03.phx.gbl... > > "Jan Kucera" <kuc***@lupacovka.cz> wrote in message > news:2FF1228F-68DC-4800-A665-C7AF3F238C4B@microsoft.com... >> But if the data model changes, I have to change the data layer as well as >> the business layer, haven't I? > > Not necessarially. It's actually quite rare (and not a good idea) to > change the database's interface (names of stored procs., table design, > etc.). But it is quite common to change databases entirely. So, if the > "old" database was, say, Oracle and the new one is SQL Server, your data > layer would need to be re-written for different data access, but the SP > names as well as input/output parameters don't neccessarially change. > None of this need affect the business layer at all. suppose are independent of the database engine and it takes the concrete connection objects in a constructor. Is this a bad idea? Aren't the Transact SQL statements compatible between Oracle, SQL server and others? Thanks, Jan Thus wrote Jan,
Show quote > "Scott M." <s-mar@nospam.nospam> wrote in message Only the parts that are part of ANSI SQL (or where the syntax happens to > news:%23i72fhJyGHA.3632@TK2MSFTNGP03.phx.gbl... > >> "Jan Kucera" <kuc***@lupacovka.cz> wrote in message >> news:2FF1228F-68DC-4800-A665-C7AF3F238C4B@microsoft.com... >> >>> But if the data model changes, I have to change the data layer as >>> well as the business layer, haven't I? >>> >> Not necessarially. It's actually quite rare (and not a good idea) to >> change the database's interface (names of stored procs., table >> design, etc.). But it is quite common to change databases entirely. >> So, if the "old" database was, say, Oracle and the new one is SQL >> Server, your data layer would need to be re-written for different >> data access, but the SP names as well as input/output parameters >> don't neccessarially change. None of this need affect the business >> layer at all. >> > Actually my data layer uses DbConnection, DbCommand and others class > which I suppose are independent of the database engine and it takes > the concrete connection objects in a constructor. Is this a bad idea? > Aren't the Transact SQL statements compatible between Oracle, SQL > server and others? be identical outside of any standard). Using an abstraction layer for the actual database implementation can induce a false sense of portability... Cheers, -- Joerg Jooss news-re***@joergjooss.de What if your database wasn't a database but was the file system?
I'm writing software at the moment where the data could be stored directly on the file system, or in the database. My rule-of-thumb is "Don't have a 'domain specific' code in the business layer" Where 'domain specific' means ADO/ASP/whatever code, Kevin Jones Jan Kucera wrote: Show quote > > "Scott M." <s-mar@nospam.nospam> wrote in message > news:%23i72fhJyGHA.3632@TK2MSFTNGP03.phx.gbl... >> >> "Jan Kucera" <kuc***@lupacovka.cz> wrote in message >> news:2FF1228F-68DC-4800-A665-C7AF3F238C4B@microsoft.com... >>> But if the data model changes, I have to change the data layer as >>> well as the business layer, haven't I? >> >> Not necessarially. It's actually quite rare (and not a good idea) to >> change the database's interface (names of stored procs., table design, >> etc.). But it is quite common to change databases entirely. So, if >> the "old" database was, say, Oracle and the new one is SQL Server, >> your data layer would need to be re-written for different data access, >> but the SP names as well as input/output parameters don't >> neccessarially change. None of this need affect the business layer at >> all. > > Actually my data layer uses DbConnection, DbCommand and others class > which I suppose are independent of the database engine and it takes the > concrete connection objects in a constructor. Is this a bad idea? Aren't > the Transact SQL statements compatible between Oracle, SQL server and > others? > > Thanks, > Jan Exactly! I've been referring to databases, but your point IS the point. By
separating the data access layer from the business layer, you *could* switch data stores without upsetting the business layer. Show quote "Kevin Jones" <kjonesNOSPAM@develop.com> wrote in message news:%233VFkToyGHA.2516@TK2MSFTNGP06.phx.gbl... > What if your database wasn't a database but was the file system? > > I'm writing software at the moment where the data could be stored directly > on the file system, or in the database. > > My rule-of-thumb is "Don't have a 'domain specific' code in the business > layer" Where 'domain specific' means ADO/ASP/whatever code, > > Kevin Jones > > Jan Kucera wrote: >> >> "Scott M." <s-mar@nospam.nospam> wrote in message >> news:%23i72fhJyGHA.3632@TK2MSFTNGP03.phx.gbl... >>> >>> "Jan Kucera" <kuc***@lupacovka.cz> wrote in message >>> news:2FF1228F-68DC-4800-A665-C7AF3F238C4B@microsoft.com... >>>> But if the data model changes, I have to change the data layer as well >>>> as the business layer, haven't I? >>> >>> Not necessarially. It's actually quite rare (and not a good idea) to >>> change the database's interface (names of stored procs., table design, >>> etc.). But it is quite common to change databases entirely. So, if the >>> "old" database was, say, Oracle and the new one is SQL Server, your data >>> layer would need to be re-written for different data access, but the SP >>> names as well as input/output parameters don't neccessarially change. >>> None of this need affect the business layer at all. >> >> Actually my data layer uses DbConnection, DbCommand and others class >> which I suppose are independent of the database engine and it takes the >> concrete connection objects in a constructor. Is this a bad idea? Aren't >> the Transact SQL statements compatible between Oracle, SQL server and >> others? >> >> Thanks, >> Jan This is a complex subject.
I suggest you read the following book which is widely considered to the the authority on the subject: Expert VB 2005 Business Objects (by Rocky Lhotka) http://www.amazon.com/exec/obidos/ASIN/1590596315/steveorrnet-20/104-9341293-6121515?creative=327641&camp=14573&adid=0MN5QNXF4KW05MF3J962&link_code=as1 or here's the C# version if you prefer: http://www.amazon.com/exec/obidos/ASIN/1590596323/steveorrnet-20/104-9341293-6121515?creative=327641&camp=14573&adid=0DX2YFNHQP6HRCVHN7X0&link_code=as1 Show quote "MS newsgroup" <k***@jeromegroup.com> wrote in message news:elfI4JHyGHA.4024@TK2MSFTNGP02.phx.gbl... >I don't have clear reasons why we need business logic layer and data logic >layer instead of having only data logic layer. > > Are there any good reasons for that? > >
Show quote
"Steve C. Orr [MVP, MCSD]" <St***@Orr.net> wrote in message Good answer, Steve. Now if I could only get our more experienced developers news:usN9ehJyGHA.4092@TK2MSFTNGP04.phx.gbl... > This is a complex subject. > I suggest you read the following book which is widely considered to the > the > authority on the subject: > > Expert VB 2005 Business Objects (by Rocky Lhotka) > http://www.amazon.com/exec/obidos/ASIN/1590596315/steveorrnet-20/104-9341293-6121515?creative=327641&camp=14573&adid=0MN5QNXF4KW05MF3J962&link_code=as1 > > or here's the C# version if you prefer: > http://www.amazon.com/exec/obidos/ASIN/1590596323/steveorrnet-20/104-9341293-6121515?creative=327641&camp=14573&adid=0DX2YFNHQP6HRCVHN7X0&link_code=as1 > > -- > I hope this helps, > Steve C. Orr, MCSD, MVP > http://SteveOrr.net > to actually read the books, and understand them, I'd be one step further ahead. -- --- 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