mclark1129
New member
- Joined
- Apr 3, 2009
- Messages
- 3
- Programming Experience
- 1-3
Hello,
I have been trying to learn how to design my applications so that they are separated into Presentation, Business, And Data layers in an effort to write applications that are extendable, maintainable, and all that other object-oriented goodness that you see all over the place. While I understand the basic concept and the logic behind why it is a good idea, I fall short when trying to realize an actual implementation. I've seen a myriad of tutorials on this subject all explaining the same thing in different ways, each with their own slightly different style of implementation. I'm not sure what part of the understanding I am missing, but when I try to code these layers I feel like I end up making it way more complicated than it needs to be and doing myself more harm than good. I feel like turning to some of the VB.net gurus out there and asking for your advice directly might do me some good
. I would consider the application I am working on currently to be a great example of an application that would benefit from being broken into layers, yet is also simple enough to learn the concepts without being bogged down with the complexities of an enterprise-level application.
I am writing a forms application to help manage product inventory and ordering for restaurants and bars using Sql CE as the database. I intend on making the application scalable to web app using Web Forms and SQL Server, so it's easy to see why these layers would help me.
One of the tables I have in my database is Products. The fields include ID, ProductID, Name, CategoryID, and DistributorID. In order to represent a record in the table I've written a ProductModel class that contains the exact same fields as the Products table. For my data layer, I've written a ProductDAO class that handles executing the SQL on the database and returning a ProductModel object or List(Of ProductModel) depending on the type of query. For my business layer, I've written a Product class that stores a ProductModel object in a field called Details. My presentation layer will access these fields by using myProduct.Details.ID, or myProduct.Details.Name, etc. Currently, I have a shared method (Product.GetAllProducts()) that returns a List(Of Product) which I want to use for databinding to various controls in my application (in my initial attempts, databinding Windows Forms controls to a non-SQL datasource has been less than successful). In order to handle getting a single object or creating new Products I use constructors of the Product class. And finally, while I'm not exactly there yet, I will have a Save() method that persists Product.Details to the database
Dim myProduct As New Product() 'Creates a new product
Dim myProduct As New Product(25) 'Gets the product with ID=25 from the database and loads it into myProduct.
My logic behind all of this is that I want the codebehind of my forms to solely interact with the code from my Product class so that when I write a ProductDAO For SQL server I can switch it out without my forms being aware at all. Also, when I upsize to a Web Forms apps, it will be much easier to write code that calls simple and direct methods from the Product class and I can reuse the Business logic over and over again (thus saving me time and increasing my profits!).
So that's it in a nutshell (at least one part of my app). I'm curious to know from an experienced developer what parts of this I'm getting right and what parts I'm confused about. What corners am I painting myself into this way, and what approach should I be taking that would work better for my situation. Your advice is greatly appreciated, and well help get me over a hurdle I've been trying to cross for quite some time.
Thanks!
Mike C.
I have been trying to learn how to design my applications so that they are separated into Presentation, Business, And Data layers in an effort to write applications that are extendable, maintainable, and all that other object-oriented goodness that you see all over the place. While I understand the basic concept and the logic behind why it is a good idea, I fall short when trying to realize an actual implementation. I've seen a myriad of tutorials on this subject all explaining the same thing in different ways, each with their own slightly different style of implementation. I'm not sure what part of the understanding I am missing, but when I try to code these layers I feel like I end up making it way more complicated than it needs to be and doing myself more harm than good. I feel like turning to some of the VB.net gurus out there and asking for your advice directly might do me some good
. I would consider the application I am working on currently to be a great example of an application that would benefit from being broken into layers, yet is also simple enough to learn the concepts without being bogged down with the complexities of an enterprise-level application.I am writing a forms application to help manage product inventory and ordering for restaurants and bars using Sql CE as the database. I intend on making the application scalable to web app using Web Forms and SQL Server, so it's easy to see why these layers would help me.
One of the tables I have in my database is Products. The fields include ID, ProductID, Name, CategoryID, and DistributorID. In order to represent a record in the table I've written a ProductModel class that contains the exact same fields as the Products table. For my data layer, I've written a ProductDAO class that handles executing the SQL on the database and returning a ProductModel object or List(Of ProductModel) depending on the type of query. For my business layer, I've written a Product class that stores a ProductModel object in a field called Details. My presentation layer will access these fields by using myProduct.Details.ID, or myProduct.Details.Name, etc. Currently, I have a shared method (Product.GetAllProducts()) that returns a List(Of Product) which I want to use for databinding to various controls in my application (in my initial attempts, databinding Windows Forms controls to a non-SQL datasource has been less than successful). In order to handle getting a single object or creating new Products I use constructors of the Product class. And finally, while I'm not exactly there yet, I will have a Save() method that persists Product.Details to the database
Dim myProduct As New Product() 'Creates a new product
Dim myProduct As New Product(25) 'Gets the product with ID=25 from the database and loads it into myProduct.
My logic behind all of this is that I want the codebehind of my forms to solely interact with the code from my Product class so that when I write a ProductDAO For SQL server I can switch it out without my forms being aware at all. Also, when I upsize to a Web Forms apps, it will be much easier to write code that calls simple and direct methods from the Product class and I can reuse the Business logic over and over again (thus saving me time and increasing my profits!).
So that's it in a nutshell (at least one part of my app). I'm curious to know from an experienced developer what parts of this I'm getting right and what parts I'm confused about. What corners am I painting myself into this way, and what approach should I be taking that would work better for my situation. Your advice is greatly appreciated, and well help get me over a hurdle I've been trying to cross for quite some time.
Thanks!
Mike C.
