When should you create a user defined datatype or just use objects?

[Andy B.]

I have many different objects in my project like Events, NewsArticles,
Subscribers, MailingLists, Addresses, Venues, FAQ collections, FAQQuestions,
Songs, Statistics, Different types of reports, Categories of different types
(Events, Venues) and so on. When should I consider using objects (classes)
or data types (structures)? Also, should/can I practically put the data
access logic into the objects/datatypes? or should I leave those for
somewhere else?

 

[Tom Shelton]

I have many different objects in my project like Events, NewsArticles,
Subscribers, MailingLists, Addresses, Venues, FAQ collections, FAQQuestions,
Songs, Statistics, Different types of reports, Categories of different types
(Events, Venues) and so on. When should I consider using objects (classes)
or data types (structures)? Also, should/can I practically put the data
access logic into the objects/datatypes? or should I leave those for
somewhere else?

For the most part Structures probably should be avoided. Their primary use is
really in interop scenario's. Other then that, unless you want value type
symantics - they really don't bring a lot of value to the table. So, my
personal preference is to prefere classes over structures.

As for the data access code - well, I tend not to put it in the data objects.
I tend to keep the domain objects simple objects with very little
functionality. Logic goes in the BAL (Buisness Access Layer) and the Data
Access in the DAL (Data Access Layer). The domain objects are simple DTO's
(Data Transport Objects) for passing infomation between the two layers. The
UI only sees the BAL and the DTO's and knows nothing of the DAL - only the BAL
accesses the DAL. But, that's my preference. Others may disagree.

 

[sloan]

I prefer to only send IDataReaders, DataSets (usually strong), scalars, or
voids from the DataLayer.

The BAL uses the return items from the DAL (usually an IDataReader) to
populate BusinessObjects and BusinessObjectCollection.

I would stick with objects.

Full example at:
http://sholliday.spaces.live.com/feed.rss

These 3 have the basic setup: All examples are downloadable. C# code
however. (But a good learning exercise is to take the mini examples and
convert it to VB.NET)
WCF with Interface Development
Custom Objects and Tiered Development II // 2.0
Custom Objects/Collections and Tiered Development

 

[Tom Shelton]

I prefer to only send IDataReaders, DataSets (usually strong), scalars, or
voids from the DataLayer.

The BAL uses the return items from the DAL (usually an IDataReader) to
populate BusinessObjects and BusinessObjectCollection.

I actually let the DAL populate the objects - using reflection and custom
mapping attributes.

 

[Andy B.]

For the most part Structures probably should be avoided. Their primary
use is
really in interop scenario's. Other then that, unless you want value type
symantics - they really don't bring a lot of value to the table. So, my
personal preference is to prefere classes over structures.

As for the data access code - well, I tend not to put it in the data
objects.
I tend to keep the domain objects simple objects with very little
functionality. Logic goes in the BAL (Buisness Access Layer) and the Data
Access in the DAL (Data Access Layer). The domain objects are simple
DTO's
(Data Transport Objects) for passing infomation between the two layers.
The
UI only sees the BAL and the DTO's and knows nothing of the DAL - only the
BAL
accesses the DAL. But, that's my preference. Others may disagree.

Ok. So it generally should go like this:
1. The object should just carry data from 1 layer to another and that is it.
2. There should be a business layer that the object is given to. This deals
with any custom logic/validation to the object with any business rules
needed to be applied.
3. Once the business layer gets done with the object, it sends it to the
data access layer which does any database validation/rules and sends it to
the database.

Am I missing any layers and their order? The other question would be What do
you name the business and data layers? and do you create multiple layers for
each type of object?

 

[sloan]

Yeah, I realize that is another ( and legitimate ) method.

The thing that mine does is make the DataStore ( RDBMS or other) very
agnostic.
As, any RDBMS can be "got at" via IDataReader's or DataSets (or scalars or
voids of course)
..
Note that I always use the interface and not the concrete (SqlDataReader as
one example of a concrete IDataReader).

So I would label this "style" and not necessarily a right or wrong.

 

[Tom Shelton]

Yeah, I realize that is another ( and legitimate ) method.

The thing that mine does is make the DataStore ( RDBMS or other) very
agnostic.
As, any RDBMS can be "got at" via IDataReader's or DataSets (or scalars or
voids of course)
.
Note that I always use the interface and not the concrete (SqlDataReader as
one example of a concrete IDataReader).

So I would label this "style" and not necessarily a right or wrong.

I agree in fact, I do a similar thing. Our two styles are not mutually
exclusive

Isn't diversity a good thing

 

[sloan]

You need to read thru this article....at least twice.
Bookmark it, and read it again in 2 weeks.

http://msdn.microsoft.com/en-us/library/ms978496.aspx

It gives you the pro's and con's of different methods.

 

[Cor Ligthert[MVP]]

Tom,

I am not sure if I understand you, however, probably I don't like the way
you use it.
I have almost all my live discussed with people who wanted to do things in a
way as it was usable with punch cards.
This sounds very much like that to me.

Cor