Business Logic Architecture

[Chad Grooms, MCSD >> [VB.NET,C#,ASP.NET] > [VB.NET]

Hey all,

I have a few questions regarding .NET BLL design. I am a somewhat
self-taught developer with limited resources, so I know there are some
concepts here and there that I might have missed along the way. To understand
my question, it might be best for me to explain my situation...I'll try to
keep it short. :)

Currently, I explicitly define classes for each object I have created, and
mirror this design in the database. For example, If I want to create a
note-taking program, I build a class for a NoteItem with all the properties
and methods for that Note, along with a NoteCollection class that inherits
ArrayList to collect the NoteItems, sort, etc. I would (obviously) have
tables in the database (SQL Server) that hold information about the NoteItems.

Now, my questions.

1. I have yet to find anyone that can validate this structure. Explicitly
defining classes to match the database design seems to clarify the
application architecture. The only problem I have with this design is the
amount of code repetition, due to the similarity of each object's design. Is
this a logical approach?

2. It seems as though I could dynamically create a similar environment with
a DataSet. However, the structure is more implied than explicit, so it is
kind of hard to keep track of the process of using each object. Is this a
better alternative to my design, or is there any other design alternatives I
have not explored?

3. If my design is acceptable, does anyone know if there is a specific name
for this type of design (beyond "object oriented")? I feel kind of dumb not
being able to just reference a term to describe my techniques.

Sorry to talk everyone's ears off. Thanks for reading through all of this.
Any help would be greatly appreciated.

[Me]

Chad,

Sounds like a decent way to do things to me.. I am sure there are
better/worse ways to code that people will point out but I say "do what
feels right to you" since you are the one that has to update/fix the code in
the end anyway! If you are comfortable with it, and it works well for you,
then why change it!

Going the route of using a DataSet has some good advantages - you do not
have to code the classes at all really!! Just the methods that will perform
work on the data. Not to mention that if your scheme changes there is little
that you have to change in code in terms of classes. :-)

As for "what do you call it" not sure.. But take a look on the web for
Programming Patterns (one site I found was
http://pages.cpsc.ucalgary.ca/~kremer/patterns/ but there are many more that
came up).

Good luck!

<Chad Grooms, MCSD >; <C#>; ">" <"ASP."@discussions.microsoft.com> wrote in
message news:80**********************************@microsof t.com...

Hey all,

I have a few questions regarding .NET BLL design. I am a somewhat
self-taught developer with limited resources, so I know there are some
concepts here and there that I might have missed along the way. To
understand
my question, it might be best for me to explain my situation...I'll try to
keep it short. :)

Currently, I explicitly define classes for each object I have created, and
mirror this design in the database. For example, If I want to create a
note-taking program, I build a class for a NoteItem with all the
properties
and methods for that Note, along with a NoteCollection class that inherits
ArrayList to collect the NoteItems, sort, etc. I would (obviously) have
tables in the database (SQL Server) that hold information about the
NoteItems.

Now, my questions.

1. I have yet to find anyone that can validate this structure. Explicitly
defining classes to match the database design seems to clarify the
application architecture. The only problem I have with this design is the
amount of code repetition, due to the similarity of each object's design.
Is
this a logical approach?

2. It seems as though I could dynamically create a similar environment
with
a DataSet. However, the structure is more implied than explicit, so it is
kind of hard to keep track of the process of using each object. Is this a
better alternative to my design, or is there any other design alternatives
I
have not explored?

3. If my design is acceptable, does anyone know if there is a specific
name
for this type of design (beyond "object oriented")? I feel kind of dumb
not
being able to just reference a term to describe my techniques.

Sorry to talk everyone's ears off. Thanks for reading through all of this.
Any help would be greatly appreciated.

[Michael Nemtsev]

Hello Chad Grooms, MCSD [VB.NET,C#,ASP.NET] [VB.NET" Chad Grooms, MCSD,

1) What have u done is normal practice. Important thins is - it should be
clear for u to support it.
If u create a lot of similar project with similar business and data access
layers - try to generalize it and create your own BAL and DAL framework.
Moreover there are several instuments that can help u maping classes and
tables. See at NHibernate library and CodeSmith tool

3) It's component orient architecture

C> Currently, I explicitly define classes for each object I have
C> created, and mirror this design in the database. For example, If I
C> want to create a note-taking program, I build a class for a NoteItem
C> with all the properties and methods for that Note, along with a
C> NoteCollection class that inherits ArrayList to collect the
C> NoteItems, sort, etc. I would (obviously) have tables in the database
C> (SQL Server) that hold information about the NoteItems.
C>
C> Now, my questions.
C>
C> 1. I have yet to find anyone that can validate this structure.
C> Explicitly defining classes to match the database design seems to
C> clarify the application architecture. The only problem I have with
C> this design is the amount of code repetition, due to the similarity
C> of each object's design. Is this a logical approach?
C>
C> 2. It seems as though I could dynamically create a similar
C> environment with a DataSet. However, the structure is more implied
C> than explicit, so it is kind of hard to keep track of the process of
C> using each object. Is this a better alternative to my design, or is
C> there any other design alternatives I have not explored?
C>
C> 3. If my design is acceptable, does anyone know if there is a
C> specific name for this type of design (beyond "object oriented")? I
C> feel kind of dumb not being able to just reference a term to describe
C> my techniques.
C>
C> Sorry to talk everyone's ears off. Thanks for reading through all of
C> this. Any help would be greatly appreciated.
C>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Chad Grooms, MCSD]

Thank you for the quick response. I have been somewhat unsure of my own
practices for so long...it's nice to get an outside opinion.

Much appreciated!!!!!!

--
-Chad Grooms, MCSD
www.chadgrooms.com
"Me" wrote:

Chad,

Sounds like a decent way to do things to me.. I am sure there are
better/worse ways to code that people will point out but I say "do what
feels right to you" since you are the one that has to update/fix the code in
the end anyway! If you are comfortable with it, and it works well for you,
then why change it!

Going the route of using a DataSet has some good advantages - you do not
have to code the classes at all really!! Just the methods that will perform
work on the data. Not to mention that if your scheme changes there is little
that you have to change in code in terms of classes. :-)

As for "what do you call it" not sure.. But take a look on the web for
Programming Patterns (one site I found was
http://pages.cpsc.ucalgary.ca/~kremer/patterns/ but there are many more that
came up).

Good luck!

<Chad Grooms, MCSD >; <C#>; ">" <"ASP."@discussions.microsoft.com> wrote in
message news:80**********************************@microsof t.com...

Hey all,

I have a few questions regarding .NET BLL design. I am a somewhat
self-taught developer with limited resources, so I know there are some
concepts here and there that I might have missed along the way. To
understand
my question, it might be best for me to explain my situation...I'll try to
keep it short. :)

Currently, I explicitly define classes for each object I have created, and
mirror this design in the database. For example, If I want to create a
note-taking program, I build a class for a NoteItem with all the
properties
and methods for that Note, along with a NoteCollection class that inherits
ArrayList to collect the NoteItems, sort, etc. I would (obviously) have
tables in the database (SQL Server) that hold information about the
NoteItems.

Now, my questions.

1. I have yet to find anyone that can validate this structure. Explicitly
defining classes to match the database design seems to clarify the
application architecture. The only problem I have with this design is the
amount of code repetition, due to the similarity of each object's design.
Is
this a logical approach?

2. It seems as though I could dynamically create a similar environment
with
a DataSet. However, the structure is more implied than explicit, so it is
kind of hard to keep track of the process of using each object. Is this a
better alternative to my design, or is there any other design alternatives
I
have not explored?

3. If my design is acceptable, does anyone know if there is a specific
name
for this type of design (beyond "object oriented")? I feel kind of dumb
not
being able to just reference a term to describe my techniques.

Sorry to talk everyone's ears off. Thanks for reading through all of this.
Any help would be greatly appreciated.

[DylanM]

Hi Chad,

What you propose is fine in smaller systems, but when you're working with
larger relational databases 1 object per table is often not the way to go.
For your objects to be useful at GUI level, they will probably need to be
'borrowing' descriptive fields from related tables etc. Otherwise you might
find yourself with a cascading object model that needs to keep making
database calls to get all the information it needs to display to the user
(learnt this the hard way!).

There are OR mappers out there that are good (NHibernate has been mentioned)
and this is definitely a good way to go, but the technology to use definitely
depends on the problem at hand.

In terms of OO \ Database design, I do think writing Use Cases before you've
written a line of code or designed a table is a good idea. It makes you
really think about what you're trying to achieve, plan through possible logic
etc. Without a doubt, since I've started employing OO and OO techniques, once
I actually start writing code my work rate is much more efficient & less
likely to be full of errors!

Just my 2 cents...!

"Chad Grooms, MCSD >> [VB.NET,C#,ASP.NET]" wrote:

Hey all,

I have a few questions regarding .NET BLL design. I am a somewhat
self-taught developer with limited resources, so I know there are some
concepts here and there that I might have missed along the way. To understand
my question, it might be best for me to explain my situation...I'll try to
keep it short. :)

Currently, I explicitly define classes for each object I have created, and
mirror this design in the database. For example, If I want to create a
note-taking program, I build a class for a NoteItem with all the properties
and methods for that Note, along with a NoteCollection class that inherits
ArrayList to collect the NoteItems, sort, etc. I would (obviously) have
tables in the database (SQL Server) that hold information about the NoteItems.

[Chad Grooms, MCSD]

Thanks Dylan. This is what I was concerned with - that my larger applications
would outgrow this design. I will definitely heed your warnings in my
situation.

In response to the cascading connection issue, I have considered this (I ran
into the same problem about a year ago). To avoid this, I allow the
individual objects to be created by themselves, or to be created by parent
classes by defining multiple constructors for each object.

Thanks again!
--
-Chad Grooms, MCSD
www.chadgrooms.com
"DylanM" wrote:

Hi Chad,

What you propose is fine in smaller systems, but when you're working with
larger relational databases 1 object per table is often not the way to go.
For your objects to be useful at GUI level, they will probably need to be
'borrowing' descriptive fields from related tables etc. Otherwise you might
find yourself with a cascading object model that needs to keep making
database calls to get all the information it needs to display to the user
(learnt this the hard way!).

There are OR mappers out there that are good (NHibernate has been mentioned)
and this is definitely a good way to go, but the technology to use definitely
depends on the problem at hand.

In terms of OO \ Database design, I do think writing Use Cases before you've
written a line of code or designed a table is a good idea. It makes you
really think about what you're trying to achieve, plan through possible logic
etc. Without a doubt, since I've started employing OO and OO techniques, once
I actually start writing code my work rate is much more efficient & less
likely to be full of errors!

Just my 2 cents...!

"Chad Grooms, MCSD >> [VB.NET,C#,ASP.NET]" wrote:

Hey all,

I have a few questions regarding .NET BLL design. I am a somewhat
self-taught developer with limited resources, so I know there are some
concepts here and there that I might have missed along the way. To understand
my question, it might be best for me to explain my situation...I'll try to
keep it short. :)

Currently, I explicitly define classes for each object I have created, and
mirror this design in the database. For example, If I want to create a
note-taking program, I build a class for a NoteItem with all the properties
and methods for that Note, along with a NoteCollection class that inherits
ArrayList to collect the NoteItems, sort, etc. I would (obviously) have
tables in the database (SQL Server) that hold information about the NoteItems.

[Chad Grooms, MCSD]

I've seen NHibernate pop up a few times...I'll take a look. Thanks!

--
-Chad Grooms, MCSD
www.chadgrooms.com
"Michael Nemtsev" wrote:

Hello Chad Grooms, MCSD [VB.NET,C#,ASP.NET] [VB.NET" Chad Grooms, MCSD,

1) What have u done is normal practice. Important thins is - it should be
clear for u to support it.
If u create a lot of similar project with similar business and data access
layers - try to generalize it and create your own BAL and DAL framework.
Moreover there are several instuments that can help u maping classes and
tables. See at NHibernate library and CodeSmith tool

3) It's component orient architecture

C> Currently, I explicitly define classes for each object I have
C> created, and mirror this design in the database. For example, If I
C> want to create a note-taking program, I build a class for a NoteItem
C> with all the properties and methods for that Note, along with a
C> NoteCollection class that inherits ArrayList to collect the
C> NoteItems, sort, etc. I would (obviously) have tables in the database
C> (SQL Server) that hold information about the NoteItems.
C>
C> Now, my questions.
C>
C> 1. I have yet to find anyone that can validate this structure.
C> Explicitly defining classes to match the database design seems to
C> clarify the application architecture. The only problem I have with
C> this design is the amount of code repetition, due to the similarity
C> of each object's design. Is this a logical approach?
C>
C> 2. It seems as though I could dynamically create a similar
C> environment with a DataSet. However, the structure is more implied
C> than explicit, so it is kind of hard to keep track of the process of
C> using each object. Is this a better alternative to my design, or is
C> there any other design alternatives I have not explored?
C>
C> 3. If my design is acceptable, does anyone know if there is a
C> specific name for this type of design (beyond "object oriented")? I
C> feel kind of dumb not being able to just reference a term to describe
C> my techniques.
C>
C> Sorry to talk everyone's ears off. Thanks for reading through all of
C> this. Any help would be greatly appreciated.
C>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/members/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche