VS.NET/class design/OO wizards: Please evaluate my scheme for abstracting the details of my applicat

[Guest]

Hi. This is a a semi-newbie question about how to store arbitrary
information about my apps
such that I can code quickly, mimizing complexity and the number of things I
have to hold in my brain. I am going to describe the scheme I'm using, and
then
I'm going to describe another scheme that may be more OO but that I have not
tried.
I'm hoping someone vastly smarter and more experienced than me will critique
this
and/or tell me a yet better scheme.

I have a complicated database that maintains a lot of information about my
many applications. The design of the database is decent. The config settings
include things like

ApplicationID
ContentCategoryIDs
RelationTypeIDs

I have started using, and learning VS.NET is an extremely focused way.
VS.NET is great: I love the ability to comment methods and properties and
classes via "///" and have that documentation everywhere. I love how I can
prompt myself to take the "next right action" by unfolding a series of
nested classes in intellisense.

For my configuration-related information, I wrote a class called
"UwnConfig", and I nested a series of classes beneath that. Configuration
info such as ApplicationID and CategoryID are listed as static properties.
Excerpts of this
nested class structure (with phony info) follow this message.

What's nice about this approach is that using Intellisense, you can "unfold"
the hiearchy in your client code as follows, getting prompted along the way
by your Intellisense comments:

public void InitializeObject(ScrapeAppID scrapeAppID)
{
if (scrapeAppID == ScrapeAppID.CoeNewsFlash)
{
this.contentcategoryid =
UwnConfig.Contentitems.ContentCategories.uwnews_uwclips_coenewsflash;
this.relationtypeid =
UwnConfig.Contentitems.RelationTypes.HeadlineToPublication;
}

What I like about this is how effectively it seems to work with
Intellisense. I am wondering if there are superior approaches that retain
Intellisense/tools/comments support.

There are a great many things I don't understand well at all -- much of my
learning has been from the Great OO Books rather than the experience of
writing scads of code -- but my sense is that a more "proper" way to do
this would be to instantiate an actual class instances associated with an
Application class, and then to read the AppID and CategoryID in as
properties of that application object. Is the following code a better
approach? In the following scenario, I'm writing into a Pdf class I've
written, and the Pdf instances need to be configured differently based on
what application they are going to be used for. So we pass an Application
object instance to the constructor for Pdf ...

public Pdf (Application myApplication)
if (myApplication.Name == "CoeNewsFlash")
this.ContentCategoryID = myApplication.ContentCategoryID;
this.RelationTypID = myApplication.RelationTypID;

I have not tested or implemented this. An appealing thing here is that lots
of complexity relating to myApplication gets hidden.

But I am wondering if in real-world use, you end up denying yourself some of
Intellisense's documentation features on larger projects, and whether that
loss should matter or not in properly constructed software. I have not
written enough code and I don't understand tools or classes deeply enough to
really know what the best approach here is.

I imagine there may be other ways to do this, perhaps using serialization
which I understand in concept but have never implemented. Again I don't have
the experience to assess what the tools implications of this might be, and
whether there are advantages to serialization that might outweigh any
disadvantages.

The skeleton of my simple nested-class approach follows. As crude as it may
be, I'm finding it vastly more appealing than doing lookups by hand,
especially since I can embed comments and such about my content.

Any guidance some of you wiser and more experience folk could offer would be
most appreciated.

Thanks,

Ken Fine
http://ideapod.com





public class UwnConfig
{
public UwnConfig()
{

}
public class Contentitems
{
public Contentitems()
{
}

public class RelationTypes
{

public RelationTypes()
{
}

public static int HeadlineToPublication = 140;
public static int ArticleToAuthor = 155;
public static int PhotoToArticle = 1237;
....

}

public class ContentCategories
{
public ContentCategories()
{
}

public static int UwnNewsRelease = 55;
public static int UwnNewsClip = 36;
public static int UwkStory =757;
public static int Slideshow = 531;
public static int Slide = 832;
}

}
}

 

[Guest]

I don't yet have any kind of comprehensive answer to the questions I asked a
few moments ago, but I have noticed at least one deficiency to a shallow and
relatively thoughtless implementation of an Application class that relies on
instances, as I suggested toward the conclusion of my last message.

The temptation is to stupidly write a simple Application class with simple
properties that it will need, e.g.

private contentcategoryid;
private appid;
private relationtypid;

If you have an application, say, "NewsletterApplication", and you're
building against a competent relational database system, you have related
entities: Publications, Headlines, Headlines Related To Headlines. Some
entities will have one "contentcategoryid" and some will have different
"contentcategoryids."

A naive approach of simply assigning these properties to the application
object instance is not going to work. One way or another, the complexity of
your database schema needs to be reflected in the code, probably by
instantiating a bunch of different objects and having a parent object keep
handle on those other objects.

The simple approach I cited at the beginning of the parent post, with simply
storing data as static properties, starts to look more appealing. It is
lousy encapsulation, but at least I can understand intuitively how to make
it work well quickly.

Thinking aloud. If anyone cares to break up this soliloquy, it would be nice
to hear another perspective.

Thanks,
Ken Fine
http://ideapod.com