0

I have read the following article from MSDN: http://msdn.microsoft.com/en-us/library/aa581779

It talks about creating a data layer, business logic layer and presentation layer and having naming conventions like getProductsDAL(), getProductsBLL() etc or even separating them into class libraries.

My question is: do developers follow this approach if .NET datasets are not used i.e. if youdo all the logic yourself e.g. have a function called getProducts, which connects to the database using a connection object and then loops through the resultset using an SQLDataReader and displays the results on the page. I am thinking about splitting functions like this into layers.

w0051977
  • 15,099
  • 32
  • 152
  • 329
  • 1
    Pity about the downvotes, this is a question that many developers ask at one stage. Read this: http://stackoverflow.com/questions/1182303/n-tiered-vs-n-layered-architecture-design and this http://en.wikipedia.org/wiki/Multitier_architecture – callisto Jul 19 '12 at 11:38

1 Answers1

2

If you are set on doing it your way:
Your data layer will consist of methods that open a connection, execute a query/stored proc and return a dataset or datatable. This layer does not receive connection info from the layer above, and only returns query results from every method. Connections are instantiated at this level.

Your business logic layer contains methods that call one or more datalayer methods each. Example: Adding a new user also means setting up permissions for that user, so DL.InsertUser(params...) and DL.SetPermissions(int Userid, List permissions) is called by BL.AddNewUser(params...). This BL method could also call another DL method that gets a list of default permissions to assign the new user

Your UI Layer would call the BL.AddNewUser(params...) with all the appropriate new user details

callisto
  • 4,921
  • 11
  • 51
  • 92
  • Do you think this is good practice? I have inherited an ASP.NET app that has low cohesion and tight coupling in the classes. I am trying to follow a structured approach to future development. Is this a pattern that you would follow? – w0051977 Jul 19 '12 at 11:37
  • I have built systems like that with high cohesion and loose coupling. Just be consistent in your choice of method placement in correct classes and and keeping classes from serving multiple purpose. – callisto Jul 19 '12 at 11:43
  • The presentation layer calls the business logic layer and the business logic layer calls the data access layer? I was thinking about returning SQLDataReaders from the data layer, which can be looped through at the business logic later. The business logic layer could then return a table to put on the page. – w0051977 Jul 19 '12 at 11:53
  • I am nearly ready to mark this answered. Would you create interfaces on the data access layer and business logic layer if necessary? – w0051977 Jul 19 '12 at 11:56
  • Call: UI > BL > DL. Results: DL > BL > UI. Easy pattern to follow: Allways return datasets from your DL. Even if they are empty( which should be almost never!) It would make more sense to bind the BL than the DL to an interface. DO you need interfaces? Multiple types/numbers of parameters means binding the DL to an interface is going to be a bit of tail wagging the dog. – callisto Jul 19 '12 at 11:59
  • I am thinking about implementing an inheritance hierarchy in the business layer where some sub type classes share method names, so I can use an interface to polymophically create an instance of the appropriate type. Perhaps the interface could be implemented by the business layer class and the associated data layer class - after all they will have the same function names?. – w0051977 Jul 19 '12 at 12:04
  • I like your idea of the creating an instance of the correct type. Not sure why you want to include the DL though. – callisto Jul 19 '12 at 12:43
  • It is just for consistency. Would you just create interfaces for the BL layer? Perhaps I am over thinking this. – w0051977 Jul 19 '12 at 13:41
  • The consistency you strive for will be enforced from the BL downwards, since you will only call DL methods from the BL anyway. – callisto Jul 20 '12 at 11:25
  • if you don't have inheritance and polymorphism in your data class hierarchy then would you just have everything in one class for the data tier (this is my last question)? – w0051977 Aug 02 '12 at 19:11
  • I have seen single data classes become bloated over time, so no. Even if you think you will never have to override or inherit, chances are later down the line you'll start to think of refactoring. Removing clutter by splitting a bloated class into smaller classes based on some simple criteria is a very effective way to make your code more manageable and readable which are both very good. Trust me, working on one giant data class without any logical grouping of methods is less pleasant than working on smaller classes that overall contain the same functionality as the fat one. – callisto Aug 05 '12 at 20:26
  • Is there a design pattern you can recommend for this? Perhaps bridge? I think you are saying don't use polymorphism and inheritance in the data classes but do split them up. – w0051977 Aug 05 '12 at 21:22