I've disagreed pretty sharply with MS on the subject of data access... but I
guess that's mostly just because of their examples of implementation. The
second article is interesting; thanks for making me take a another look.
Paul
"John Bell" <jbellnewsposts@hotmail.com> wrote in message
news:B6CD35F3-6D60-453D-802F-906DD9F7CCE7@microsoft.com...[color=blue]
> Hi
>
> You may want to read the patterns and practices recommendations at
>
http://msdn.microsoft.com/library/de...MSpatterns.asp
> such as
>
http://msdn.microsoft.com/library/de...tml/BOAGag.asp
>
> If you are using user input to generate you SQL make sure you code against
> SQL injection techniques. Also look at using sp_executesql to run the code
> you generate.
>
> John
>
> "PJ6" wrote:
>[color=green]
>> First up, I know I'll get some good answers here, but in general, are
>> there
>> any newsgroups devoted to overall application architecture?
>>
>> Second, sorry for cross-posting but in this case I think it's
>> appropriate, I
>> want to hear answers from both sides.
>>
>> Instead of representing inheritance in the data model, in the particular
>> project I'm working on now I've decided to do it in OO to keep it looser;
>> each class gets its own table, because the details vary, but implements
>> an
>> interface. Each class serves a static collection of itself which it loads
>> from the database. I get a master list of these items by putting all the
>> collections together into one of the common interface type.
>>
>> Obtaining a master list in this way is a great simplification over the
>> route
>> I would have normally chosen - I otherwise would have had a "base" table
>> containing the properties of the common interface, and requiring that all
>> "inheritor" tables have a foreign key to it. I already know that this is
>> a
>> little iffy since 1 to 1 relationships aren't exactly a good thing. Of
>> course, I could have thrown everything into one table containing all the
>> fields in every class, which poses its own problems and ugliness. Not
>> liking
>> either of these options, I decided to dump representing inheritance at
>> all
>> in the database. And this led me in a new direction...
>>
>> Partially through the convenience of generics, I've noticed that since
>> I'm
>> caching everything locally already, it's easy to just do dictionary
>> lookups
>> through all this data to find subsets. I'm in effect sidestepping the
>> normal
>> chore of setting up stored procedures. Actually, I use attributes to
>> specify
>> table names and fields to populate in each class, so I have no
>> pre-written
>> SQL at all in the entire application. I sort of like it, but this is
>> something new for me - I normally push a lot of stuff as far as I can
>> down
>> into the data model; now I'm just using the database as a "dumb"
>> container.
>>
>> So to those other architects out there, what is your take on this
>> approach?
>>
>> Thanks,
>> Paul
>>
>> P.S. - some additional information
>> 1. yes, in this case, the user will often need access to all the data at
>> once since there will be several different global analysis views
>> 2. the data will change only weekly through an automated process
>>
>>
>>[/color][/color]
