Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
robvolk
Most Valuable Yak
15732 Posts |
 Posted - 2004-12-13 : 17:59:20
|
| Just wanted to throw out an idea. Does anyone program their user interfaces through a type of widget class? Let's say you have quite a few dropdown or other list controls that require data from a database. Do you put the code for these into a separate class that you can call from any page, or do each one on the page? I'm sure most people do the latter, I'm hoping to hear from people who've done it another way. Any opinions on constantly hitting the DB vs. writing to files or putting in cache/app variables?I'm sure there are a number of available 3rd party controls out there that work this way, but I'm interested in learning how to do it myself, and what types of features/problems to look out for. I'm already looking at storing common datasets in a cache object, for example. I'd really like to centralize the code for data-driven interface controls and want to hear if there is any particular upside or downside that isn't readily apparent.Thanks! |
|
|
jhermiz
3564 Posts |
Posted - 2004-12-13 : 18:14:48
|
| Rob,I would definately recommend writing a seperate class for all your "widgets". The benefit is management of code, size, time, cost, and efficiency. This goes for client applications as well as for web based applications. One of the benefits for a developer is the code is so reusable you can practically use it on any page or any client application. With client application you benefit from having to register these widgets or dll's on various client machines. You can also have these "registered" dll's running on their own application server, which may take the load off the client machine. The problem here is maintenance and administration of the actuall app server. If you have the time and money why not ?The recent project I have worked on included the same code that could be called from any page. The great thing about .net (if you are using .net) is the flexibilty. However, even if you are not using .net most all programming languages give you the flexibility to pass defaults or not for variable names. So let us say you are trying to tap into a db using a stored procedure which requires some kind of key. If the datatypes are the same why should you waste your time rewriting the same call in a different page when you can generalize it into one encapsulated reusable class.It has saved me days if not months of development on sometihng like this. I definately recommend that you do this using the OOP technique and make it as reusable as you can. Of course not everything can be reusable but most db driven applications can be.Thanks,Jon |
 |
|
|
chadmat
The Chadinator
1974 Posts |
Posted - 2004-12-13 : 18:56:08
|
| The downside is it's usability in a web farm environment. I am assuming there will be some sort of logic that invalidates a cached dataset (If the underlying dat changes). You have to take into account that the stale data may (Depending on how you cache it) be cached on many web servers. Maintaining cached data across webservers.As far as the data access code is concerned, I would hope the data retrieval code is centralized, rather than being on each page. That is how I try to design my apps.-Chadhttp://www.clrsoft.comSoftware built for the Common Language Runtime. |
|
|
|
Kristen
Test
22859 Posts |
Posted - 2004-12-13 : 20:55:49
|
| Dunno if this helps - our stuff is rather specific to what we do!We have specific SProc calls for picklists, based on Table [nick]name and Column name. Our "form management stuff" automatically calls the picklist function for any appropriate column (i.e. our Meta Data indicates that the column uses a picklist).We also ahve a caching system on the web server. Each "page" has to gather security data from the database, and as part of that resultset a recordset is included with general information, including the latest "batch number" of data which should be cached. If the batch number is "newer" than the cache then a further SProc is called to get any new recordsets for the cache. Thus the cache is updated "just in time".The cached data for such recordsets is stored in XML (in a format simulating recordset data).Calls to SProcs go through a single "Call An Sproc" function. If the Sproc's name is in a lookup list of "cached results" the data is retrieved from the XML cache, instead of calling the database.So, for example, "usp_Country_PickList" might be deemed to be cached whereas "usp_Customer_Picklist" might not [too volatile].Kristen |
|
|
|
robvolk
Most Valuable Yak
15732 Posts |
Posted - 2004-12-14 : 09:55:35
|
Thanks for the input everyone. I wish the decision were up to me, I would've done it a while ago if it were. "Centralized data access" is a somewhat novel concept here  and a lot of the code was not written with it in mind (I'm only the DBA here) It's been cleaned up quite a bit, but there's a long way to go. And making significant changes is painful and breaks a lot of things, so it will have to go one baby step at a time.As a follow-up question, any advice on how "centralized" to make the data access? Any particular, practical limits on this? We have multiple databases on multiple servers, but most apps pull from only one DB. I'd prefer not to use a generic (web) service; we're already throwing around too much data with too much overhead and we don't have the proper hardware to manage it. I can use it for small things like dropdowns and lists but can't have it for datagrids and the like.Thanks. |
|
|
|
|
|
|
|
|
Interface Question