would class be useful here?
mp
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 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
news:ihmuu2$kh1$1...@news.eternal-september.org...
> 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
"Jeff Johnson" <i....@enough.spam> wrote in message
news:ihmvlk$l0m$1...@news.eternal-september.org...
> "mp" <nos...@Thanks.com> wrote in message
> news:ihmuu2$kh1$1...@news.eternal-september.org...
>> 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
>
>> 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.
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
"Arne Vajh�j" <ar...@vajhoej.dk> wrote in message
news:4d3f00ae$0$23756$1472...@news.sunsite.dk...
> On 25-01-2011 11:49, mp wrote:
>> I'm thinking through a design decision.
[]
>
> 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
Rick Lones
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.
-rick-
Arne Vajhøj
> "mp"<nos...@Thanks.com> wrote in message
>> 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).
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.
>> 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.
Objects of some classes sounds more type safe than XML.
:-)
Arne
Arne Vajhøj
> mp wrote:
>> 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!?!
>
> 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
"Arne Vajhøj" <ar...@vajhoej.dk> wrote in message
news:4d3f0fd1$0$23757$1472...@news.sunsite.dk...
> On 25-01-2011 12:54, Rick Lones wrote:
>> mp wrote:
>>> 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
"Arne Vajh�j" <ar...@vajhoej.dk> wrote in message
news:4d3f0f7c$0$23757$1472...@news.sunsite.dk...
> On 25-01-2011 12:01, Jeff Johnson wrote:
>> "mp"<nos...@Thanks.com> wrote in message
>>> then StockData objects can be responsible for entering/reading
>>> themselves from the database???
>
> 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
"Rick Lones" <Wrlo...@YcharterZ.net> wrote in message
news:W7E%o.39768$8_2...@newsfe17.iad...
> mp wrote:
>> 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
> "Arne Vajh�j"<ar...@vajhoej.dk> wrote in message
> news:4d3f0f7c$0$23757$1472...@news.sunsite.dk...
>> On 25-01-2011 12:01, Jeff Johnson wrote:
>>> "mp"<nos...@Thanks.com> wrote in message
>>>> then StockData objects can be responsible for entering/reading
>>>> themselves from the database???
> []
>>
>> Objects of some classes sounds more type safe than XML.
>>
>> :-)
>
> 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
"Arne Vajhøj" <ar...@vajhoej.dk> wrote in message
news:4d3f3733$0$23757$1472...@news.sunsite.dk...
> On 25-01-2011 15:40, mp wrote:
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
> "Arne Vajhøj"<ar...@vajhoej.dk> wrote in message
> news:4d3f3733$0$23757$1472...@news.sunsite.dk...
>> On 25-01-2011 15:40, mp wrote:
>>> "Arne Vajhøj"<ar...@vajhoej.dk> wrote in message
>>> news:4d3f0f7c$0$23757$1472...@news.sunsite.dk...
>>>> On 25-01-2011 12:01, Jeff Johnson wrote:
>>>>> "mp"<nos...@Thanks.com> wrote in message
>>>>>> 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.
>
> the compiler wouldn't know perhaps but i would
> :-)
But type safe usually means checked by compiler not by
programmer.
Arne
Jeff Johnson
news:4d3f45d5$0$23757$1472...@news.sunsite.dk...
> On 25-01-2011 16:44, mp wrote:
>> news:4d3f3733$0$23757$1472...@news.sunsite.dk...
>>> On 25-01-2011 15:40, mp wrote:
>>>> news:4d3f0f7c$0$23757$1472...@news.sunsite.dk...
>>>>> On 25-01-2011 12:01, Jeff Johnson wrote:
>>>>>> "mp"<nos...@Thanks.com> wrote in message
>>>>>>> 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
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
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 news:ihmuu2$kh1$1...@news.eternal-september.org...
Jeroen van Langen
"Jeroen van Langen" schreef in bericht
news:24f90$4d4e7c3a$d52ec445$6...@news.chello.nl...
mp
"Jeroen van Langen" <jvanl...@live.nl> wrote in message
news:d6c3d$4d4e8110$d52ec445$60...@news.chello.nl...
> ?Offcourse the property Name of class stock needs to be public :S
>
> "Jeroen van Langen" schreef in bericht
> news:24f90$4d4e7c3a$d52ec445$6...@news.chello.nl...
>
> ?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
> {
[]
[]