would class be useful here?

[mp]

I'm thinking through a design decision.
I have a class Stock : Investment{}

part of the process is reading 85 bits of information about each stock each
day.

the info may be stored in a database to view change over time.
perhaps i will create charts or reports in future?

if i read the data and put it directly in the database
i can hear a voice inside my head saying "that's "data-centric" vs oop"???

does it make sense to create a class StockData?
and give it 85 properties to hold each piece of info?

then StockData objects can be responsible for entering/reading
themselves from the database???

and a class with 85 constructors???
sounds like i may get some
feedback on that idea!?!

thanks
mark

 

[Arne Vajhøj]

I'm thinking through a design decision.
I have a class Stock : Investment{}

part of the process is reading 85 bits of information about each stock each
day.

the info may be stored in a database to view change over time.
perhaps i will create charts or reports in future?

if i read the data and put it directly in the database
i can hear a voice inside my head saying "that's "data-centric" vs oop"???

does it make sense to create a class StockData?
and give it 85 properties to hold each piece of info?

then StockData objects can be responsible for entering/reading
themselves from the database???

and a class with 85 constructors???
sounds like i may get some
feedback on that idea!?!

I am a bit skeptical about 85 properties. Can't some of that
be in other classes or arrays or List<>?

Whether you will have a Stock class in Domain Layer
that is used by both Business Logic Layer and Data Access
Layer or you will have a Stock class in Business Logic Layer
and a StockData class in Data Access Layer is up to you
and what fits best with your context.

Arne

 

[Jeff Johnson]

I'm thinking through a design decision.
I have a class Stock : Investment{}

part of the process is reading 85 bits of information about each stock
each day.

the info may be stored in a database to view change over time.
perhaps i will create charts or reports in future?

if i read the data and put it directly in the database
i can hear a voice inside my head saying "that's "data-centric" vs oop"???

Maybe, but sometimes that's the better way.

does it make sense to create a class StockData?
and give it 85 properties to hold each piece of info?

Hmmm, not sure if StockData is necessary. If it's just a middleman for
Stock, I probably wouldn't do it. But then I've never been a real
Enterprise-y kind of guy, with business layers and data layers and
factories, oh my! Unless I'm working on a really big Enterprise project, of
course. (My co-worker, on the other hand, uses our business framework on
even the smallest of projects. I think it's a sledgehammer to kill a fly,
but I admit that the fly ends up just as dead.)

As far as 85 properties go, that seems excessive. However, if these are
truly 85 individual, completely-unrelated pieces of data then what else can
you really do? If, however, some of the properties group logically together
then perhaps some constiuent classes are in order. (In other words, an
object model.)

then StockData objects can be responsible for entering/reading
themselves from the database???

Whatever holds the data ought to be able to read and write itself to the
database, yes. That reading and writing may go through a helper class,
though (your business layer).

and a class with 85 constructors???

No. Absolutely not. But a blob of XML as a single argument? Sounds better.
Or, if you get the object model thing going, maybe a few classes as
arguments. But then of course you'll have constructors for those classes,
and their classes, etc.

All of this, of course, is off the top of my head. I haven't been following
your Stock/Investment threads that closely, so I don't have the depth of
understanding to make a "professional" judgement.

 

[mp]

I'm thinking through a design decision. []
if i read the data and put it directly in the database
i can hear a voice inside my head saying "that's "data-centric" vs
oop"???

Maybe, but sometimes that's the better way.

i won't tell ralph you said that <g>


[]
(My co-worker, on the other hand, uses our business framework on

even the smallest of projects. I think it's a sledgehammer to kill a fly,
but I admit that the fly ends up just as dead.)

it's way overkill for what i'm doing, but trying to learn what's been
suggested...at this point it is what it is...

As far as 85 properties go, []

? If, however, some of the properties group logically together

then perhaps some constiuent classes are in order. (In other words, an
object model.)

i'm sure i can do some grouping of them to subdivide

Whatever holds the data ought to be able to read and write itself to the
database, yes. That reading and writing may go through a helper class,
though (your business layer).


No. Absolutely not. But a blob of XML as a single argument? Sounds better.

then the class internally sends things where they need to be?

Or, if you get the object model thing going, maybe a few classes as
arguments. But then of course you'll have constructors for those classes,
and their classes, etc.

All of this, of course, is off the top of my head. I haven't been
following your Stock/Investment threads that closely, so I don't have the
depth of understanding to make a "professional" judgement.

thanks for your input
mark

 

[mp]

I'm thinking through a design decision.

[]

I am a bit skeptical about 85 properties. Can't some of that
be in other classes or arrays or List<>?

i'm sure i can do some grouping,

Whether you will have a Stock class in Domain Layer
that is used by both Business Logic Layer and Data Access
Layer or you will have a Stock class in Business Logic Layer
and a StockData class in Data Access Layer is up to you
and what fits best with your context.

Arne

thanks for your thoughts
mark

 

[Arne Vajhøj]

Whatever holds the data ought to be able to read and write itself to the
database, yes. That reading and writing may go through a helper class,
though (your business layer).

A data class should know about its data and which of them that
should be persisted.

But it should not know whether it should be persisted to SQLServer,
Oracle, XML, CSV or something else - so there can not be too
much persistence logic in them.

No. Absolutely not. But a blob of XML as a single argument? Sounds better.
Or, if you get the object model thing going, maybe a few classes as
arguments. But then of course you'll have constructors for those classes,
and their classes, etc.

Objects of some classes sounds more type safe than XML.



Arne

 

[Arne Vajhøj]

85 properties if a class probably means approx. 85 columns if a database
table. So in one sense it's the same either way, except that with the
database you get the persistence and querying capabilities versus
rolling your own. So database would probably be my choice. But like the
others, I wonder if it really makes sense to have that many different
attributes. If you were designing it as a relational DB table would it
have 85 columns, if reasonably normalized? Or would you right away be
decomposing it into a set of smaller tables with relationships between
them?

Of course, using a database doesn't mean that you WON'T need an object
model of some sort within your app to fetch and manipulate this stock
data regardless of how and where it is persisted. You've already bought
into that.

Also, where does the number "85 constructors" come from? I don't see any
obvious dependency with the number of properties.

I assumed that he meant a constructor with 85 arguments.

Arne

 

[mp]

I'm thinking through a design decision.

[]

Also, where does the number "85 constructors" come from? I don't see any
obvious dependency with the number of properties.

I assumed that he meant a constructor with 85 arguments.

Arne

oops :-\
yes i mean args...duh...i think the cat typed that one

 

[mp]

[]

Objects of some classes sounds more type safe than XML.



Arne

well, the xml would have come from serializing the objects so
the type comes along for the ride, no?
mark

 

[mp]

I'm thinking through a design decision.
I have a class Stock : Investment{}

part of the process is reading 85 bits of information about each stock
each day.
[] !?!

thanks
mark

85 properties if a class probably means approx. 85 columns if a database
table.
right

So in one sense it's the same either way, except that with the database
you get the persistence and querying capabilities versus rolling your own.
So database would probably be my choice. But like the others, I wonder if
it really makes sense to have that many different attributes. If you were
designing it as a relational DB table would it have 85 columns, if
reasonably normalized? Or would you right away be decomposing it into a
set of smaller tables with relationships between them?

yes, i now realize i'll want to group them in some way

Of course, using a database doesn't mean that you WON'T need an object
model of some sort within your app to fetch and manipulate this stock data
regardless of how and where it is persisted. You've already bought into
that.

Also, where does the number "85 constructors" come from? I don't see any
obvious dependency with the number of properties.

-rick-

brain fart typo,,, i mean args
mark

 

[Arne Vajhøj]

then StockData objects can be responsible for entering/reading
themselves from the database???

[]

Objects of some classes sounds more type safe than XML.

well, the xml would have come from serializing the objects so
the type comes along for the ride, no?

Not really.

There are no way to have the C# compiler enforce that
string contains XML from XML serialization. That will
be a runtime check.

Arne

 

[mp]

On 25-01-2011 12:01, Jeff Johnson wrote:
then StockData objects can be responsible for entering/reading
themselves from the database??? []

Objects of some classes sounds more type safe than XML.

well, the xml would have come from serializing the objects so
the type comes along for the ride, no?

Not really.

There are no way to have the C# compiler enforce that
string contains XML from XML serialization. That will
be a runtime check.

Arne

i meant i would be serializing and deserializing in my code
the compiler wouldn't know perhaps but i would

anyway, i'm going to look into the db option
thanks
mark

 

[Arne Vajhøj]

On 25-01-2011 12:01, Jeff Johnson wrote:
then StockData objects can be responsible for entering/reading
themselves from the database???
[]

Objects of some classes sounds more type safe than XML.



well, the xml would have come from serializing the objects so
the type comes along for the ride, no?

Not really.

There are no way to have the C# compiler enforce that
string contains XML from XML serialization. That will
be a runtime check.

i meant i would be serializing and deserializing in my code
the compiler wouldn't know perhaps but i would

But type safe usually means checked by compiler not by
programmer.

Arne

 

[Jeff Johnson]

On 25-01-2011 15:40, mp wrote:
On 25-01-2011 12:01, Jeff Johnson wrote:
then StockData objects can be responsible for entering/reading
themselves from the database???
[]

Objects of some classes sounds more type safe than XML.



well, the xml would have come from serializing the objects so
the type comes along for the ride, no?

Not really.

There are no way to have the C# compiler enforce that
string contains XML from XML serialization. That will
be a runtime check.

i meant i would be serializing and deserializing in my code
the compiler wouldn't know perhaps but i would

But type safe usually means checked by compiler not by
programmer.

At some point we all do things in our code that can't be checked at compile
time. In a closed environment like this, bad XML means a bug, which will be
caught and fixed. It's not like he's going to be distributing this to other
users who can (and WILL) pass any old bunch of crap to the constructor.

 

[Arne Vajhøj]

On 25-01-2011 15:40, mp wrote:
On 25-01-2011 12:01, Jeff Johnson wrote:
then StockData objects can be responsible for entering/reading
themselves from the database???
[]

Objects of some classes sounds more type safe than XML.



well, the xml would have come from serializing the objects so
the type comes along for the ride, no?

Not really.

There are no way to have the C# compiler enforce that
string contains XML from XML serialization. That will
be a runtime check.

i meant i would be serializing and deserializing in my code
the compiler wouldn't know perhaps but i would

But type safe usually means checked by compiler not by
programmer.

At some point we all do things in our code that can't be checked at compile
time. In a closed environment like this, bad XML means a bug, which will be
caught and fixed. It's not like he's going to be distributing this to other
users who can (and WILL) pass any old bunch of crap to the constructor.

1) I would still try and make things as type safe as possible.

2) The "this code will only be used for X months for purpose Y" concept
is known to slide - code tend to live a lot longer than expected and
to be used in completely unexpected contexts.

Arne

 

[Jeroen van Langen]

?Hi,

If these bits of information are the same on all stocks, yes those would be
properties.
But, only when your software does something with it. (like calculations)

If it's only a import process, I would make something like this:

class AllStocks
{
private readonly Dictionary<string, Stock> _stocks = new
Dictionary<string, Stock>();

public Stock[] Stocks
{
get
{
return _stocks.Values.ToArray(); // never expose the list (you
want to have control on it)
}
}

public Stock this[string name]
{
get
{
return _stocks[name];
}
}

public Stock AddStock(string name)
{
if (_stocks.ContainsKey(name))
throw new Exception(name + " already exists"); // normally you'd
make a new type of exception so you can handle it different while importing

Stock result = new Stock(name);
_stocks.Add(name, result);
return result;
}
}

class Stock
{
private readonly Dictionary<string, BitsOfInformation>
_bitsOfInformation = new Dictionary<string, BitsOfInformation>();
private string Name { get; private set; }

public Stock(string name)
{
Name = name;
}

public BitsOfInformation[] BitsOfInformation
{
get
{
return _bitsOfInformation.Values.ToArray(); // never expose the
list (you want to have control on it)
}
}

public BitsOfInformation this[string name]
{
get
{
return _bitsOfInformation[name];
}
}

public BitsOfInformation AddBitsOfInformation(string name, object value)
{
if (_bitsOfInformation.ContainsKey(name))
throw new Exception(name + " already exists"); // normally you'd
make a new type of exception so you can handle it different while importing

BitsOfInformation result = new BitsOfInformation(name, value);
_bitsOfInformation.Add(name, result);
return result;
}
}

class BitsOfInformation
{
public string Name { get; private set; }
public object Value { get; set; }

public BitsOfInformation(string name, object value)
{
Name = name;
Value = value;
}
}

How do you relate them to database fields?
You could define a mapping table to map the bit of information name/key to a
database fieldname. (like a Dictionary<string, string>)

The same for the database, either you can make a table with stocks and a
huge table with 85 columns and link it to a stock record. (master-detail)
Or make it dynamic.

Tables:
// The stock table to store the stocks.
Stocks (StockId, StockName )

// The stock items to store all bits of information about a stock.
BitsOfInformationItems (StockInfoItemId, ItemName)

// The stock value of bits of information each datetime. (intersection
(or cross) table on stock and BitsOfInformation)
BitsOfInformationValues (StockInfoValueId, StockId, StockInfoItemId,
DateTime, Value)


This way you can handle various of BitsOfInformation on a stock.

Regards,
Jeroen

"mp" schreef in bericht
I'm thinking through a design decision.
I have a class Stock : Investment{}

part of the process is reading 85 bits of information about each stock each
day.

the info may be stored in a database to view change over time.
perhaps i will create charts or reports in future?

if i read the data and put it directly in the database
i can hear a voice inside my head saying "that's "data-centric" vs oop"???

does it make sense to create a class StockData?
and give it 85 properties to hold each piece of info?

then StockData objects can be responsible for entering/reading
themselves from the database???

and a class with 85 constructors???
sounds like i may get some
feedback on that idea!?!

thanks
mark

 

[Jeroen van Langen]

?Offcourse the property Name of class stock needs to be public :S

"Jeroen van Langen" schreef in bericht

?Hi,

If these bits of information are the same on all stocks, yes those would be
properties.
But, only when your software does something with it. (like calculations)

If it's only a import process, I would make something like this:

class AllStocks
{
private readonly Dictionary<string, Stock> _stocks = new
Dictionary<string, Stock>();

public Stock[] Stocks
{
get
{
return _stocks.Values.ToArray(); // never expose the list (you
want to have control on it)
}
}

public Stock this[string name]
{
get
{
return _stocks[name];
}
}

public Stock AddStock(string name)
{
if (_stocks.ContainsKey(name))
throw new Exception(name + " already exists"); // normally you'd
make a new type of exception so you can handle it different while importing

Stock result = new Stock(name);
_stocks.Add(name, result);
return result;
}
}

class Stock
{
private readonly Dictionary<string, BitsOfInformation>
_bitsOfInformation = new Dictionary<string, BitsOfInformation>();
private string Name { get; private set; }

public Stock(string name)
{
Name = name;
}

public BitsOfInformation[] BitsOfInformation
{
get
{
return _bitsOfInformation.Values.ToArray(); // never expose the
list (you want to have control on it)
}
}

public BitsOfInformation this[string name]
{
get
{
return _bitsOfInformation[name];
}
}

public BitsOfInformation AddBitsOfInformation(string name, object value)
{
if (_bitsOfInformation.ContainsKey(name))
throw new Exception(name + " already exists"); // normally you'd
make a new type of exception so you can handle it different while importing

BitsOfInformation result = new BitsOfInformation(name, value);
_bitsOfInformation.Add(name, result);
return result;
}
}

class BitsOfInformation
{
public string Name { get; private set; }
public object Value { get; set; }

public BitsOfInformation(string name, object value)
{
Name = name;
Value = value;
}
}

How do you relate them to database fields?
You could define a mapping table to map the bit of information name/key to a
database fieldname. (like a Dictionary<string, string>)

The same for the database, either you can make a table with stocks and a
huge table with 85 columns and link it to a stock record. (master-detail)
Or make it dynamic.

Tables:
// The stock table to store the stocks.
Stocks (StockId, StockName )

// The stock items to store all bits of information about a stock.
BitsOfInformationItems (StockInfoItemId, ItemName)

// The stock value of bits of information each datetime. (intersection
(or cross) table on stock and BitsOfInformation)
BitsOfInformationValues (StockInfoValueId, StockId, StockInfoItemId,
DateTime, Value)


This way you can handle various of BitsOfInformation on a stock.

Regards,
Jeroen

"mp" schreef in bericht
I'm thinking through a design decision.
I have a class Stock : Investment{}

part of the process is reading 85 bits of information about each stock each
day.

the info may be stored in a database to view change over time.
perhaps i will create charts or reports in future?

if i read the data and put it directly in the database
i can hear a voice inside my head saying "that's "data-centric" vs oop"???

does it make sense to create a class StockData?
and give it 85 properties to hold each piece of info?

then StockData objects can be responsible for entering/reading
themselves from the database???

and a class with 85 constructors???
sounds like i may get some
feedback on that idea!?!

thanks
mark

 

[mp]

nice, thanks for that example

?Offcourse the property Name of class stock needs to be public :S

"Jeroen van Langen" schreef in bericht

?Hi,

If these bits of information are the same on all stocks, yes those would
be
properties.
But, only when your software does something with it. (like calculations)

If it's only a import process, I would make something like this:

class AllStocks
{ []

"mp" schreef in bericht
I'm thinking through a design decision.
I have a class Stock : Investment{}

part of the process is reading 85 bits of information about each stock
each
day.

[]