DAL or BLL? How to implement objects

[Nemisis]

Hi everyone,

i am creating my own DAL and BLL, and i am not using typed datasets.
My problem is that in my DAL i have a Save method whos signiture looks
something like:


Save(ID as integer, name as string, .......


Within my BLL, i call then same method (the business layer version)
something like this


Save (pCompany as company)


The latter of the two seems better to me as u dont have to write out
all the variables, and a problem could occur if someone passed in a
value of the wrong type.


I think it would be alot better to have both the DAL and BLL signiture
look like


Save (pCompany as company)


If i wanted to do this, were would i store the business objects? The
DAL?? The BLL?? Or do i even create a separate class library that
both the DAL and BLL must reference??


Also, if i do this, i will have to change my DAL to return objects,
instead of returning DataRows, DataTables and DataSets, like it does
at the moment, is this right? i am not merging the two by accident am
i??


I do not want to using any of the microsoft code that you can download,

but if someone could please let me know about the above, i would be
very greatful.


Cheers

 

[Mikeon]

If i wanted to do this, were would i store the business objects? The

DAL?? The BLL?? Or do i even create a separate class library that
both the DAL and BLL must reference??

If you want to return business objects from DAL you have to reference
them from DAL and since you want also to be able to reference DAL from
BLL you get a circular reference.
What you need is a some kind of Data Transfer Object which you will use
to move the data between BLL and DAL. There are few possible choices
here. Either you use what is provided to you by Microsoft in a form of
DataSet/DataTable/Something which are not strongly typed and do not
hide the underlying database structure from you. The other choice is
creating your own - strongly typed DTO's and package the data inside
such an object before moving between layers.
The DTO should of course be defined in a separate project as the
DataSet is.

Hope this helps a little.

 

[Mikeon]

The DTO should of course be defined in a separate project as the

DataSet is.

I should have mentioned that using custom DTOs means a lot of code that
is required to populate and read data to and from such objects.

 

[sloan]

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp
Find the heading labeled
Deploying Business Entities
(about 2/3's the way down)

by defining custom entity classes in a common assembly to be deployed on
multiple tiers.

There needs to be an assembly that lives outside of the tiers.

This is where you'd but your Company object.


Also see my blog at:
http://sholliday.spaces.live.com/?_...ogview&_c=blogpart&partqs=amonth=5&ayear=2006

I have a downloadable example. I chose the #1 (in the "Deploying Business
Entities" section)

The entire microsoft article (above url) is good to read.

 

[Nemisis]

Thanks for the comments so far, I have tried to download the code on
your blog, but i get an error when i try to extract the file?? Says
File Not Found. I would like to see your SQLHelper class, can you
explain this a lil more for me??

This may sound a lil stupid but i guess a DTO is a Data Transfer
Object? And what does this do exactly? Or is this what is ment when
you store your business objects ina separate project?

Sorry if the questions sound a bit ..... well stupid,

Thanks again

 

[Nemisis]

Thanks for the comments so far, I have tried to download the code on
your blog, but i get an error when i try to extract the file?? Says
File Not Found. I would like to see your SQLHelper class, can you
explain this a lil more for me??

This may sound a lil stupid but i guess a DTO is a Data Transfer
Object? And what does this do exactly? Does it populate the business
object with data from a dataset/datareader, or is this what is ment
when you store your business objects ina separate project?

Sorry if the questions sound a bit ..... well stupid,

Thanks again

 

[sloan]

I just redownloaded it. Thru IE and Firefox. Both worked.

Make sure you download it local ~then open it up in WinZip.

SQLHelper is just the
Data Access Application Block v 2.0 (specific to Sql Server )
http://aspnet.4guysfromrolla.com/articles/062503-1.aspx
That's like 3 year old stuff.

Now, the flavor is the EnterpriseLibrary application blocks.

SQLHelper just a helper , that encapsulates common data access logic. it is
not the "Assembly living outside the Tiers"

The
Data.DataSets project/assembly is (my) assembly living outside of the other
Tiers.


................

 

[Nemisis]

I have downloaded the code again, but it says that some of the files
are password protected??

I have had a look at the other code, and it should be bale to answer a
few questions i have had, regarding how to populate your data with
relationships etc.

I will give this ago, and let you know if i need your EXPERTISE again.
lol

Thanks again

 

[Nemisis]

Sloan,

Thanks again for the examples, this is my first real OOP project so
things are changing rapidly, but for the better, i think.

I am going to take your advice on creating a separate class library to
hold my business objects.

One thing i am not sure about, is that, for the DAL, the object only
needs a certain amount of fields, as these are the fields that will be
saved in the database, but in my business layer the object may need
some additional fields and properties. Should i put all the fields and
properties into the class object, or would it be better practice to
create a separate library of class objects, and then in my business
layer, i could create another company object that inherits from the
separate class object?? Or should the separate library be a library of
interface objects??

 

[Mikeon]

by defining custom entity classes in a common assembly to be deployed on

multiple tiers.

In my opinion Business Entities should live only in the business layer.
Pushing those entities between layers has some major disadvantages. For
example suppose you would like to have some kind of lazy load on your
properties. If we had a simple n-tier layout where BLL is right above
the DAL we can call DAL methods directly from BLL to load our lazy
loaded properties. Such as a ClassRoom object with GetStudents method.
How would you implement this in a lazy load manner if you have no
referrence (direct or indirect) to DAL?
More problems appear when you try to return your entities from web
service, where you can only return data and not behavior.
And speaking of behavior, the most important thing about business
entities is the behavior they encapsulate I do not think it would be
possible to move the behavior between layers in one entity and still
keep the application logically consistent.
Take for example a Teacher object with a GradeStudents method, what
would you need this method for in a DAL?

Of course I'm not saying the approach is bad. I'm only trying to show
that this is a very complex issue and MS articles are not always the
best source - they are DataSet/DataTable lovers after all ;-)

 

[Nemisis]

Mikeon,

Thanks for your comments, but can you explain it a lil more, i am not
sure if i completely understand?

Am i right in thinking, that i should create a separate library of
interface objects then?? Then reference these interfaces in my DAL and
BLL??

 

[Mikeon]

Thanks for your comments, but can you explain it a lil more, i am not

sure if i completely understand?

Am i right in thinking, that i should create a separate library of
interface objects then?? Then reference these interfaces in my DAL and
BLL??

Take a look at my blog where I describe the idea and there is also a
sample solution there:

http://vaultofthoughts.net/MovingDataBetweenTiers.aspx

 

[Nemisis]

Mikeon,

Thanks for that, your article and code makes alot of sense, and i am
confident now that i am doing the right thing, in creating the DTO.

One other question, if you dont mind, if i create the DTO object in the
separate library, and then reference the DTO library in my BLL, is it
ok if the BLL object inherits the properties etc of the DTO object??
This would save typing most data types etc twice? Is this not a good
idea for a reason i havent thought of??

Thanks again

 

[Nemisis]

Mikeon,

One thing you dont show in your example, is the retrieval of data via
the DTO? I would be interested in seeing how you do that.

 

[Nemisis]

Mikeon,

I didnt mean retreval sorry, i ment how do you return a collection of
objects from the DAL when your collections are defined in BLL??

 

[Mikeon]

One other question, if you dont mind, if i create the DTO object in the

separate library, and then reference the DTO library in my BLL, is it
ok if the BLL object inherits the properties etc of the DTO object??
This would save typing most data types etc twice? Is this not a good
idea for a reason i havent thought of??

When doing OOP always try to think in terms of what is logical first
and not what would help you write less code.
So in this case when you take into consideration that inheritance is a
"is a" relationship which means that if type B inherits from A then B
is a type of A like in BiologyTeacher is a Teacher. Does Teacher is a
kind of DTOTeacher? I think not and so I would preffer more code over
the non-logical design.
More over there is also a good advice to favor composition over
inheritance, which means that you can store the DTO object inside your
BLL object and just expose some properties which will use the DTO as a
data store. This way you will save some in terms of code needed for
constructing and moving the DTO's.
Additionally inheriting from DTO would close all other possibilities of
inheritance due to the single inheritance constraint.
But of course it is you how will decide. I can only give you some
theory to base your decision on.

 

[Mikeon]

I didnt mean retreval sorry, i ment how do you return a collection of

objects from the DAL when your collections are defined in BLL??

I don't know if I understand, but if you have a group of teachers to
return then I would return an array of DTOTeacher, and then load a
collection from this in BLL.
Does this answer your question?

 

[Nemisis]

I don't know if I understand, but if you have a group of teachers to
return then I would return an array of DTOTeacher, and then load a
collection from this in BLL.
Does this answer your question?

Mikeon,

Thanks for the first reply, but on the second i mean about loading
relationship collections.

So if you have a Teacher and a teacher has many students how would you
load that if i was loading in ALL teachers.

Loading many teachers with many students? Does that make sense?

 

[Mikeon]

So if you have a Teacher and a teacher has many students how would you

load that if i was loading in ALL teachers.

Loading many teachers with many students? Does that make sense?

There are few possible solutions here. Either you do a lazy load for
the sub-properties (Students) - i.e.: return a collection of teachers
without students loaded and then in the Students property when it is
accessed for a given teacher, load it from the database the same way as
you would load a collection of all students, but this time do it only
for the students for the current teacher.
If you have a scenario where you know that you will be using each of
the teacher and each of his students it would be not performance-wise
to make a call to the database every time. In this case when returning
a teacher I would also return his students as a field of the DTOTeacher
class. I would try to get the whole result in the DAL as a single
database query.
But I possible and if it would hurt not performance I personally
preffer the lazy load approach.

 

[Nemisis]

There are few possible solutions here. Either you do a lazy load for
the sub-properties (Students) - i.e.: return a collection of teachers
without students loaded and then in the Students property when it is
accessed for a given teacher, load it from the database the same way as
you would load a collection of all students, but this time do it only
for the students for the current teacher.
If you have a scenario where you know that you will be using each of
the teacher and each of his students it would be not performance-wise
to make a call to the database every time. In this case when returning
a teacher I would also return his students as a field of the DTOTeacher
class. I would try to get the whole result in the DAL as a single
database query.
But I possible and if it would hurt not performance I personally
preffer the lazy load approach.

I understand, i thnk the last approach would be better for us, but may
have to have an option to load all the information as well.

Since i would be loading data for multiple students, is it not good
practice to define a collection of students within the DTO layer? I
have made a collection class within my business layer for my student
collections, it seems like duplicate code to define another collectin
of students with the dto layer? Or is it better to just use a generic
list for DTO types?