Best Practices to work with databases using VB .NET
-
Dear Everyone..... Hope you will be in best of your health.... I have an immediate assignment from my boss to collect the knowledge that what are the best practices & architecture to deal with databaes, tables using vb .net... Actual problem is that i want to know simply that what way i should adopt for the subject. weather i should go with using data source managers or i should create objects, classes, procedures or whatsoever is... i can quote an example of my question as; CONTROL --> DATABINDINGS --> DATASOURCE --> DATA-ADAPTER-->DATABASE please help me... thanks Khurram
-
Dear Everyone..... Hope you will be in best of your health.... I have an immediate assignment from my boss to collect the knowledge that what are the best practices & architecture to deal with databaes, tables using vb .net... Actual problem is that i want to know simply that what way i should adopt for the subject. weather i should go with using data source managers or i should create objects, classes, procedures or whatsoever is... i can quote an example of my question as; CONTROL --> DATABINDINGS --> DATASOURCE --> DATA-ADAPTER-->DATABASE please help me... thanks Khurram
Your boss wants you to learn how to properly write a database application ? I'm all for a seperate data layer, and all SQL in stored procs. Some people swear by ORMs.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Your boss wants you to learn how to properly write a database application ? I'm all for a seperate data layer, and all SQL in stored procs. Some people swear by ORMs.
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
Dear Graus, thank you so much for the immediate response.... you have gotton my problem.... i am going for a one-hour presenation, so how i can describe in detail about the data layer... my problem is not actually the conversion but to find out the exact model which i should follow to deal with my databases. i mean what is the best method to deal with records that saves my memory, facilites me more, etc. etc. please disclose more if you can.... thanks
-
Dear Graus, thank you so much for the immediate response.... you have gotton my problem.... i am going for a one-hour presenation, so how i can describe in detail about the data layer... my problem is not actually the conversion but to find out the exact model which i should follow to deal with my databases. i mean what is the best method to deal with records that saves my memory, facilites me more, etc. etc. please disclose more if you can.... thanks
Hi, At a minimum you'll need to cover: * Ad-hoc data access * Stored procedure based DLs * Custom business objects * Template based ORM / Handmade ORM * ORM mapping tools. That list is pretty much in order from most-flexible to least-flexible, but also from most-effort to least-effort (in general). Your boss wants to hear about what the upfront cost is, how quick you can develop, how reliable your code will be, and the maintainance cost if things need to be changed. Remember your boss is less interested in the technical details, and more interested in the risks and benefits of your choices! I have to admit a certain bias towards ORM, as my company sells ORM tools. For a presentation you can certainly find a lot of "boss friendly" material on how ORM tools will benefit your development process on the site linked in my signature. Although we are writing about our products - the general gist applies to a lot of ORM tools.
Mark Churchill Director Dunn & Churchill
-
Hi, At a minimum you'll need to cover: * Ad-hoc data access * Stored procedure based DLs * Custom business objects * Template based ORM / Handmade ORM * ORM mapping tools. That list is pretty much in order from most-flexible to least-flexible, but also from most-effort to least-effort (in general). Your boss wants to hear about what the upfront cost is, how quick you can develop, how reliable your code will be, and the maintainance cost if things need to be changed. Remember your boss is less interested in the technical details, and more interested in the risks and benefits of your choices! I have to admit a certain bias towards ORM, as my company sells ORM tools. For a presentation you can certainly find a lot of "boss friendly" material on how ORM tools will benefit your development process on the site linked in my signature. Although we are writing about our products - the general gist applies to a lot of ORM tools.
Mark Churchill Director Dunn & Churchill
Dear friend, thanks once again for the nice response... you are absolutely right in your sense. I am just telling you the whole story of my last meeting with my boss. He is very conceptual and technical person. he is highly able to criticize the matters. he is straight forwardly asking me the following questions 1. What is .net framework's internal architecture? 2. What are database oriented best practices in .net? 3. how would be application design in .net? 4. overview of .net studio? 5. .net framework multilanguge support? 6. Database access (recordsets, queries, classes, parameters) 7. What is the best way to insert, delete, find and update data? other topics i have covered approximately. but now i am concentrating on database oriented best practices.. hope now you are very clear about my problem
-
Dear friend, thanks once again for the nice response... you are absolutely right in your sense. I am just telling you the whole story of my last meeting with my boss. He is very conceptual and technical person. he is highly able to criticize the matters. he is straight forwardly asking me the following questions 1. What is .net framework's internal architecture? 2. What are database oriented best practices in .net? 3. how would be application design in .net? 4. overview of .net studio? 5. .net framework multilanguge support? 6. Database access (recordsets, queries, classes, parameters) 7. What is the best way to insert, delete, find and update data? other topics i have covered approximately. but now i am concentrating on database oriented best practices.. hope now you are very clear about my problem
khurramsheraz wrote:
He is very conceptual and technical person. he is highly able to criticize the matters.
But, neither he nor you know the answers to these questions ? 1 - who cares ? If you don't know the basics, they are a google away. Anything more than that doesn't matter, certainly to database code 2 - The main thing is to let the .NET connection pool do it's work. Otherwise, no different to any other language 3 - n-tiered is always the best approach, IMO 4 - WHAT ? Have you not used it before ? 5 - resource files 6 - Buy a book on ADO.NET 7 - SQL
Christian Graus - Microsoft MVP - C++ "I am working on a project that will convert a FORTRAN code to corresponding C++ code.I am not aware of FORTRAN syntax" ( spotted in the C++/CLI forum )
-
Hi, At a minimum you'll need to cover: * Ad-hoc data access * Stored procedure based DLs * Custom business objects * Template based ORM / Handmade ORM * ORM mapping tools. That list is pretty much in order from most-flexible to least-flexible, but also from most-effort to least-effort (in general). Your boss wants to hear about what the upfront cost is, how quick you can develop, how reliable your code will be, and the maintainance cost if things need to be changed. Remember your boss is less interested in the technical details, and more interested in the risks and benefits of your choices! I have to admit a certain bias towards ORM, as my company sells ORM tools. For a presentation you can certainly find a lot of "boss friendly" material on how ORM tools will benefit your development process on the site linked in my signature. Although we are writing about our products - the general gist applies to a lot of ORM tools.
Mark Churchill Director Dunn & Churchill
Hello, It also depends on how big the company is and how many different database applications are required. I have certainly seen cases where ORM is simply not necessary because the company and /or the requirements arent too Big. I am a big fan of a 3 tier approach myself Dumb Database Layer - gets/upserts the data - if written correctly with abstract factories for each type of database (SQL, Oracle, Web Service etc.) Once this is written it can be used everywhere and only needs changing when a new type of database is going to be used. Business Layer - derived from a stongly created Base Class which holds the business rules for processing data entities. For example a User Business component or an "Order" Business component. In my case each busines component would be capable of navigating row by row or presenting a modified dataset for binding to gui. The business layer would be where most of the on going maintenance would occur. It would hold all the business rules. Ie you change the users details , therefore generate an audit record. These components could be stored in a different process or server if required. Gui/Controller layer - This takes the data from the business layer and adds it to the Gui controls and then takes any changes and passes them to the business layer- it includes some gui based validation rules ie a field is just number or a date, that kind of thing. Personally I think, for a small to perhaps medium sized company, that this gives the best framework in terms of long term maintenance costs and ease of use. Yes its a bigger pain than just binding data to controls from within each app but once the initial overhead is taken care of I see this as a very robust solution. Hope this helps Martin
life is a bowl of cherries go on take a byte
-
Hello, It also depends on how big the company is and how many different database applications are required. I have certainly seen cases where ORM is simply not necessary because the company and /or the requirements arent too Big. I am a big fan of a 3 tier approach myself Dumb Database Layer - gets/upserts the data - if written correctly with abstract factories for each type of database (SQL, Oracle, Web Service etc.) Once this is written it can be used everywhere and only needs changing when a new type of database is going to be used. Business Layer - derived from a stongly created Base Class which holds the business rules for processing data entities. For example a User Business component or an "Order" Business component. In my case each busines component would be capable of navigating row by row or presenting a modified dataset for binding to gui. The business layer would be where most of the on going maintenance would occur. It would hold all the business rules. Ie you change the users details , therefore generate an audit record. These components could be stored in a different process or server if required. Gui/Controller layer - This takes the data from the business layer and adds it to the Gui controls and then takes any changes and passes them to the business layer- it includes some gui based validation rules ie a field is just number or a date, that kind of thing. Personally I think, for a small to perhaps medium sized company, that this gives the best framework in terms of long term maintenance costs and ease of use. Yes its a bigger pain than just binding data to controls from within each app but once the initial overhead is taken care of I see this as a very robust solution. Hope this helps Martin
life is a bowl of cherries go on take a byte
Agreed. When picking tools that are going to become a part of your development process you should choose very carefully, because its going to be hard to back out of it. Also a lot of tools are very complex to use - meaning a great deal of time is spent configuring and babysitting the tools. Personally I am usually not comfortable using a tool that does more than one thing. Nothing is worse than installing a tool to handle your data layer that ends up restricting how you do things in the UI. If you are interested in an ORM product thats not overbearing for use in smaller applications, I suggest you give Diamond Binding a test drive.
Mark Churchill Director Dunn & Churchill
-
Agreed. When picking tools that are going to become a part of your development process you should choose very carefully, because its going to be hard to back out of it. Also a lot of tools are very complex to use - meaning a great deal of time is spent configuring and babysitting the tools. Personally I am usually not comfortable using a tool that does more than one thing. Nothing is worse than installing a tool to handle your data layer that ends up restricting how you do things in the UI. If you are interested in an ORM product thats not overbearing for use in smaller applications, I suggest you give Diamond Binding a test drive.
Mark Churchill Director Dunn & Churchill
Mark Churchill wrote:
your data layer that ends up restricting how you do things in the UI
agreed but you can do it another way too. for example my data layer has a factory class that contains a getdataset command where I pass the datarequest command (in the form of MS SQL) , the connection as an object and the dataprovider type) there are families of classes for each dataprovider so for example I have an OracleViaWebservice family which takes the MS SQL command, converts it to oracle SQL, uses the connectio class to find identify the correct web service location and passes the request to the web service which then uses the oracle connectstring (stored in that connection class) and issues the comand aainst an oracle DB before returning the result. now all that took time but now its written Its very extendable. If I come across a new dataprovider (ie webservice to Siebel for example) I just create a new family of generic classes to handle the process and away I go. If I come across another type of dataaccess (ie instead of processing a dataset, I need to process a er DataReader - yeah I know its a reach) then I just add the procesing code for a datareader to each existing family of classes I find that the ongoing maintenance of my data layer is practically non existant now and its generic enough not to restrict my business layer. Martin
life is a bowl of cherries go on take a byte