Lately I have had many thoughts run through my mind while I work with Visual Studio in Administrative Systems. For those following the sad story of what my blog has become (having degraded into a vent for my frustrations) kudos for having come this far. Since I work with Visual Studio 30+ hours a week, it is at the forefront of all my thoughts.
Today I successfully generated an ASP page that works through a multi-tiered data model. All information is stored in a well-formed database. A “Data Abstraction Layer” builds what VS calls a table adapter. By writing a single select statement, VS is able to generate insert, update, and delete statements using the table specified. These generated statements pass through what is called a “Business Logic Layer”. Here, the methods are setup to call into the DAL with the appropriate information. In the BLL, any logic that applies to business is defined, including security. These methods are then called by the view layer using data displays that have been bound to the methods in the BLL.
It is actually more clicking than typing, as is typical for Microsoft products. You have to work on establishing solid SQL statements, complete with ‘hacks’ needed for VS to do what you want with them. Once these are in place, define your methods, and instantiate them. After this, you are on to display work.
I have spent the better part of three days trying to understand how these easy directions are executed in a real scenario. Having SQL statements for inserting, updating, and deleting data sounds like a dream, but to instantiate them, I have found that I have to explicitly name each column when defining my methods. This absorbs a lot of the time that was saved earlier.
Manipulating the data too far outside of the sandbox that you have to work with becomes very difficult as well. Since everything is bound visually (the preferred method), extending the auto-generated code is difficult. For example, I have a search page, and depending on what the user wants to search for, I have to dynamically change the table adapters that the results view binds to. This code is like spaghetti, and is tough to interpret.
Tomorrow, I hope to find out how to implement a messaging area for capturing exceptions, and displaying information. The end result will hopefully (with some visual work) function similar to the way WordPress notifies a user of application events.