Computer Genius Blog :: aka “TheGarage”

I’m trolling through some old tech forum archives trying to track down the signatures of rogue malware programs when I came across this jewel from Ziff-Davis’ Neil J. Rubenking:

So, after reading that the big warning window is a fake, and that clicking the links on it will install programs that a) you do not want and b) are very hard to remove… you chose to surf to the site anyway?! That is a strange choice, unless you have powerful antispyware protection in place, but OK. Upon reaching the site you got a fake warning popup containing a very similar fake warning as is found in the box at the top of the example screenshot we showed. What specifically was surprising or confusing about this?

I’m thinking of the kid at the end of “Time Bandits” - “Mum, Dad, don’t touch it! It’s Eeeeeeevil!”. We said, basically, “Don’t touch this window - it’s Eeeeeeeevil!”. You touched it anyway, and got an Eeeeeeevil response (another fake warning). Seems quite consistent to me.

Of course, they always push the red button. Like Dee Dee on Dexter’s Labratory.

Share This

Although abstraction is crucial in any effort to build a class library of re-usable business objects it is important to not get carried away and become what is known in my book as a “purist”. Physical patterns don’t always match logical patterns. Something beautiful on paper may be a clusterduck to implement in the real world. Pardon my French but if you are reading this kind of dry material, you probably already speak French. Our goal here is flexibility and efficiency, not adherence to rigid dogma for the sake of purity.

As an example of the point I am trying to make above lets revisit the Data Access class for a moment. There are some purists who will say no business logic should be embedded in the data access layer and no data access functions should be found in the business layer. On paper that is correct and a proper design should reflect that. In the real world where some guy is trying to piece everything together one can either go through great contortions to satisfy the separation of concerns aspect of encapsulation as laid out by the purist, or one can have a boat load of stored procedures in the database to return pre-configured datasets.

The reason why the stored procedure scenario breaks the rules of encapsulation is because the business layer is required to know something about how to return certain sets of data from the back-end data stores. I have concluded that breaking this rule is preferable to maintaining a SQL command object in every business object. The end result is the same.

I don’t know if this is even technically breaking the encapsulation rule but I have read a couple of articles that suggest it is. In a logical diagram I can draw the stored procedures and views as business rules, which are clearly in the business layer but in a physical diagram the procedures are stored in the back end database and thus are retrieved using the connection object in the DAL. The best of both worlds.

So what I am saying here is that stored procedures will be used extensively in this project including the current Employee business object. As mentioned at the end of the previous article we need to figure out what all is needed in the employee object. One thing the Employee object will definitely need is a database connection so it will need to know how to ask the Data Access Layer (DAL) for a connection. This is likely a static property but probably should nonetheless be acquired from a system initialization mechanism, like an .ini file. The value of this property should never be the connection string as the connection string is the business of the Data Access Layer.

Also, the Employee object must know how to get data to satisfy every method and property that is to be made available according to the contract made at instantiation. If the employee object says it can produce a punch history list, the object has to know the secret words to get a punch history list back from the DAL.

The calling program says the secret words to get a new employee object with ‘1234′ as the employee id –> set myEmp = new Employee('1234')

Everything goes well and Bob Jones’ employee record is returned encapsulated in an employee object. To get Bob’s punch history, I just need to request it from the Employee object. Depending on implementation the punch history maybe stored inside the object or returned as a record set. Either way, when me.getPunchHistory() is called, the object has to know how to request it from the DAL –>

myDBConn.RunProc(’stored_proc_Punch_History’, ‘1234′)

That’s it in a nutshell. Every bit of data I may want to retrieve, such as schedule, absence, vacation, is made available through the employee object utilizing stored procedures. The basic employee stuff is populated when the employee object is instantiated, the rest is provided as needed. The good news is that from now on, whenever a new application is needed that will interact with employee data, all the data access functions are predefined and the programmer can focus on writing the needed application instead of worrying about database connections, security, SQL queries, and all the rest of the administrative stuff.

In the next article we will take a look a how to display our employee information to the user, which is in the presentation layer of an n-tier application. Decisions made here should not in any way affect what the Data Access Layer will ultimately look like. But this is one of those cases where the physical architecture of an actual enterprise environment dictates as to how the logical models are implemented. VB.net is not the best tool for implementing design patterns because of the code-behind-the-form method used in the product. Such a construct physically binds the presentation and business layers, but not necessarily logically.

As I mentioned above, this contradiction can be avoided if the developer eschews all the nice functionality provided by VB.net, namely the typed datasets available in the connection object which can bind data directly to the components on the web forms. The code is generated automatically and the SQL query results are shoved directly into the presentation layer…

Considering that we are mandated to use VB.Net as the development platform, what should we do? Use VB.Net datasets, or write our own SQL Command objects to maintain order with the model-view-controller design pattern evident in the n-tier model?

Share This

So I’ve pitched building a library of business objects as the solution to transform about a million lines of VB code sitting in a hundred or so 7- to 10-year-old Access database applications into a valuable corporate asset of reusable code objects built using current technology.

The director of the IT department is not an IT guy but he has a great interest in sorting out the huge tangle of code he inherited with his job: it is expensive to maintain, difficult to secure, and is not easy to enhance. In short, it is a strategic liability.

Prior to me coming along, the solution has always been assumed that every application would simply be re-written in something else, that something else likely being Visual Basic dot Net. Since day 1 I have been lobbying against that approach in favor of analyzing the applications and consolidating the code under a set of centrally managed business objects as defined by the companies existing back-end data structures and their application needs.

In other words, I’ve proposed… get ready for the buzzwords… to build the middleware in a multi-tiered distributed database architecture. The task is daunting and to the casual observer may seem impossible but it is doable nonetheless. Though my boss is in charge of the IT department, I would consider him a casual observer so his response, as I had hoped and expected, was “show me.” We picked one of the more sophisticated MS Access database applications in the inventory and I am in the process of converting it to an n-tiered application using object oriented design and implementation.

Because I am having to write the code as well as do the design work, as well as support the current state of the beast, getting the design laid out has been a slower process than I am accustomed. The area I support is HR/Payroll along with all the supporting applications for time and attendance, manpower scheduling, and other personnel related activities so it was a no-brainer to start off by building the employee object first since every single application will at some point need to manipulate an employee’s data in some way.

As I’ve touched on before, these objects in the business tier are built separately from both the interfaces that utilize them and the objects that actually access the SQL data stores. Ideally the business objects are built to work independently of the consuming applications and the source of the data being manipulated. This is accomplished on the application side by defining a contract between the business object and the application that consumes it: if an application requests an employee from me under certain terms (the parameter list in the constructor call) I will return an employee object with certain information (the public properties and methods). No mention is made of what the application will do with the data nor does the business object disclose how the data is made available.

On the data access side,  the business object becomes the consumer and has a contract with an object in the data access layer (an ADO.net connection object most likely.) If I know how to ask for something, say an employee’s punch history, the data access object will return the data without disclosing where it came from and without regard to what I am doing with it. We’ll get to security later.

Lets take an inventory of what we have so far towards this goal.  We have a meta-data dictionary of all the VB code base that was created with the Access documenter utility we built. We have a simple DBConnection class to serve as a basic data access layer. And now we are starting on our first business business object: the employee.

Next time we will take a closer look at the employee object and decide what we need in there and what will be the best way to set up the design. We will also be tweaking our DBConnection class as we go along to take advantage of some of the very nice features of ADO, namely the typed dataset object which looks very unwieldy but one simply cannot ignore the power of the tools provided in the class.

Share This