Binding Controls Directly to your Database 2

[jojo11]

Hi:

I have several development teams that are starting to utilize third party web controls to help develop a richer user experience. One example is infragistics.

The problem I have is with how they are using these controls.

Basically they are binding them directly to the databases.

In my opinion this completely eliminates the object oriented nature of the application by bypassing coded business logic and relies on the database and web page to hanel it.

It is sort of why I never like to hire VB developers who employed that technique. It is so easy to simply drag a few controls on a form, bind them to the database and have a working application that will probably end up in the scrap heap in a year or so since it is not flexible. (I don't need to go into the reasons why OO development is important)

I am looking for your thoughts on this as I would like to prepare a presentation to discuss this.

Thanks

-------------------------------------------
Ummm, we have a bit of a problem here....

 

[ca8msm]

Projects that incorporate multiple layers are extremely popular and can increase application performance, scalability, flexibility and code reuse to name a few things. Have a search on google for some other advantages or a detailed explanation.


____________________________________________________________
Mark,
[URL unfurl="true"]http://aspnetlibrary.com[/url]

Need help finding an answer? Try the Search Facility or read FAQ222-2244.

 

[BoostMR2]

Since this environment you are writing these application for is dynamic, you definitely want to make the applications dynamic. If not, then as you stated before, they will be trashed ina year, and that is after countless hours of maintenance to change in the app whatever changed in the environment.

I always take the extra time to make an app dynamic. A good example is servers (I do tons of network scripting). I could maintain a .txt or small DB that has all my network servers and hosts, but that is additional time (and hassle). Instead I write a script that runs, oh, once a day to update that data in said .txt or DB. I never have to touch it again, It will update itself every 24 hours, and I will be able to use it for multiple applications. Sometimes i even incorporate some fault tolerance, such as a .log, and if an error occurs have it auto-email me. Simple things like that avoid maintenance.

For you're apps, i would recommend keeping the controls seperate, writing some functions that process the data in the way you want, and then imports the data to the DB. If soemthing changes, (a user control style, the format of the data, etc) you only need change the code, not the DB input mask and keys. Much less of a hassle. The database fields themselves should stay as static as possible. This also helps to avoid errors.