Specifications

Today I embark on getting, saving, updating and deleting specifications for components within an analysis. I hope to say its done by the end of the day. This is kinda a week late. I mean, I was really hoping to have more done sooner, but support calls are coming in. You see we are in the middle of grape harvest. So the core product is being used extensively by tired and confused winemakers, enologist and cellar workers. It could be made a lot easier. In the future I hope I can do that.

Back to the LIMS project. The specifications are key to how an Analysis will be able to define the limits, ranges and hold times for each particular component. The crux of this design is that all labs within the enterprise have a stack of available components. These components make up the basis for all labs being able to exchange data. Then each lab combines those components into their specific methodology. For example, Lab X creates Metal analysis, specific to their lab, means they test for Calcium, Potassium and Sodium. Second Lab Y creates a Metal analysis, but they test for Potassium, Lithium and Beryllium. Within each analysis there are specifications for each component. Dated with a start date and end date - so at any point in time, you can see what the limits were for that component. A tree forms, Analysis has Component branches. A Component has Specification branches.

Let's see how well this works in action...

Components to Analysis

Feeling really good about getting the logic for the add component worked out. Will need to be refactored a bit, but think its smooth and workable. Even a little crispy.

So let's see if I can explain this.

Create an analysis object. Internal to that object there is an analysiscomponentlist and a second one that is not alterable. The two of them work together to determine any changes by the user.

When you save the analysis it calls a persist method that then compares the two lists.

The user adds, updates or removes from the public componentlist.

Same thing will happen for specifications. Instead of treating them as component specifications, I am treating them as analysis specifications - with the intent that they are tightly coupled to a component.

Tells of an enterprise developer, Part I

Where to begin? I guess the middle since that's where we currently stand. I'm a year into a six-month project. It's a two person application, "pushing" the limits of .Net 2.0. It stands as a prototype for how a rebuild of a bigger application might happen. The bigger project is about 10 yrs old and is built in VB 6.0.

So here we are in the middle. I pushed for a n-tier design, using OOP to define the business layer. Actually to design the whole thing. Funny, I like having to say OOP seems so retro. I mean, if I was designing structure programming of something, that is worthy of noting. But OOP is kinda the norm at this moment. Well, for the real world. Here OOP is still some new fangled buzzword along with SQL. Don't get me started. I'll save that for another post.

I intend on chronicling my adventures. I wish I had started way back, but I'll just have to post the history as I go. Welcome and enjoy.