Can anyone tell me which is the best way to go for a large VB App.? I know you can use the DE within a Data Class but is it easier to just work directly with the DE from within the App. or should you set up a Data Class for each command?
Printable View
Can anyone tell me which is the best way to go for a large VB App.? I know you can use the DE within a Data Class but is it easier to just work directly with the DE from within the App. or should you set up a Data Class for each command?
for a large app i wouldn't choose the DE at all, and of course i would never create a class for each command.
instead it is better to do a bit o research about object oriented application design. there are 2 very decent vb-oriented books i can recommend:
- doing objects in vb6 (deborah kurata)
- vb 6 business objects (rockford lhotka)
sorry for not providing a cut + paste solution,
sascha
Why would you not suggest using the data environment. I use it extensively and find that it is a clean way to execute queries,manage connections, and generate reports. But, then again, my database apps are not huge and my setup package does get rather large.
the probably cleanest way to manage ado connections and queries is just coding ado (no de and no adodc(!)).
if you decide to use the built in datareports, then it is probably a nice way to use the de in the design phase, and when done, replace the de with more flexible ado code.
i am not trying to tell you, that you are a bad programmer, when using de, but once you are familiar with de, it is only a little step to get deeper into ado and n-tier design. that little extra research will pay back in no time and will enable you to write truely scalable and maintainable apps.
if you have to port your existing app to an internet app (happens occasionaly nowadays), you will most likely not be able to reuse anything exept your database backend.
good luck
sascha
Point taken.
My point was that the de IS ADO. There is nothing you can do with ADO that the data env can't do (at least nothing that I have found). The de is kind of like using MS Access and storing all of your queries and forms, as oppoed to writing all connections and queries in a code module. I would agree with the internet and portability points, I have not come across those issues yet, and may change my tune when I do. Until then, I like using a combination of de and ADO, especially for reporting. Thanks for the feedback.
hey, thanks for the replys!!
I am very familiar with ADO and DE, and my personal preference is with the ADO. However, not so familiar with classes. One of the issues i have been stressing with is scalability as it pertains to the actual database. My original app uses an Access database and relys on code to administer the business rules. What i was thinking (and i could be wrong) was to use adodc for the business rules for lower-scale versions. This way i can use the classes with any interface and still allow the installer to pick a database.
The higher-scale versions would be strictly SQL Server, and the business rules would be governed by the database server.
As a matter of design, business rules could and should be implemented in classes and not as part of the database engine. This allows the application to use any data source and thus increases flexibility. Business rules can also be changed without changing the database design or the front end.
If the front end uses a method of a class Class.Method, the internal workings of that method can be changed without having to change the front end. This is the essence of using objects.
Cheers,
P.