N-tier layer separations and connection/interaction

[dee-u]

I happen to be experimenting based on some examples I've found on the net
but I want to be directed to the right path, those samples tend to be incomplete or misleading. In a typical N-tier scenario, which should reference which? And is the use of Data Transfer Object in accordance to any best practice that maybe existing?

EDIT: Accordingly, how does those layers supposed to connect/interact with one another eg. what does BLL passes to the DAL and what is returned to it...

[DanInManchester]

Typically in my N-tier apps I have the database then on top of that either MS data access blocks or some custom data access class that provides simplified raw database access.

On top of this sits the data access layer that takes care of the CRUD. This will usually be executing scalars, readers and non queries only.

On top of this sits the business logic/objects. This manipulates the data / business objects in accordance with the business rules and functions. I tend to use custom classes/entities.

On top of this sits the UI and any logic relevant to the display of the application interface.

Does that help or do you want more specific information?

[dee-u]

How does the different layers interact? For example, what is passed by the BLL to the DAL and what is returned to it? Doesn't the DAL references your entities?

[DanInManchester]

It depends on how you opt to do your coding. I stay away from datasets and the likes and stick to lighter weight custom objects however this does have it's draw backs for example concurreny handling.

In my setup usually I will have the business object with various properties.
When I cal the load method this will call a particular method in the DAL to get a data reader. this data reader is then consumed by the object to poulate the properties and perform any logi necessary.

When saving this object I would pass the object it self down to the DAL so that it's properties can be used to populate the parameters.

[dee-u]

I've got the ff. assemblies:

1. UI = References BLL and DTO
2. BLL = References DAL and DTO
3. DAL = References DTO
4. DTO (Business Objects)

And I'm thinking, since the BLL already references DTO is it possible that the UI won't reference it anymore since it is already referencing BLL? Could I instantiate DTO's based on reference to the BLL alone?

[DanInManchester]

It depends I've seen a number of approaches and used two myself.

My older model was to have the business entities and the business logic separately.
e.g. I would have a member entity class and a member controller class. The member entity would be passed up and down between layers. I found this approach tended to get me into a bit of a mess and inheritance didn't work that well. Maybe thats just me but I've seen the approach taken before.

Now I have one business class called member that contains all the logic associated with the class. I find this creates a tighter object model and facilitates better control of what is happening in the business entity/logic.

There are plenty of resources on Microsoft and other sites to do with these sorts of patterns and practices and you do get variation between them even when esseintially they are talking about the same thing.

[dee-u]

I am currently using your 'old model. With your newer model how and what do you passed and receive between the layers? Care to post a simple demo to illustrate such pattern? :)

[DanInManchester]

I wouldn't use this approach for a little project it's easier to mess with a dataset and other such objects and use a 'less strong' object model (if that makes any sence). I find that tight OOP in small projects is restrictive and unecessary however you need to realise that at a point if the project grows you will need to reconsider.

A simple psedo example of the business class would be...

Person Class
FirstName
Surname

_ID

Save Method
If _ID = 0 then
_ID = DAL.AddNewPerson(Me)
' add new person returns the new primary key
else
DAL.UpdatePerson(Me)
end if
end save method

Load Method(MemberID)
DataReader = DAL.LoadMember(MemberID)
FirstName = DataReader("Firstname")
LastName = DataReader("Lastname")
_ID = MemberID
close and dispose of data reader
end load method
end person class
The DAL would consume the scalars or member object properties to populate its parameters and execute whatever command text / stored proc.

[dee-u]

Based on your pseudo-code am I right in thinking that your DAL references your BLL (if that class is located in the BLL) and the BLL references your DAL? Wouldn't that cause circular reference?

[DanInManchester]

It depends what you mean exactly.

In your example (my old method) you would pass the DTO to the DAL I assume to populate parameters etc?

I'm essentially doing the same here only in this DTO it also has the methods.
If my DAL were to call the business methods then true this would be a circular method.

e.g. if I called save on my business entity then the dal that procesess the save called the save method then indeed this would be a circular reference. But The DAL simply consumes the objects properties for updating the database. Methods of the Business entity should only be called by the business layer upwards. Having said that I'm not sure how you would go about enforcing that.

[dee-u]

Hmmmnnn... Based on your experience and knowledge is such pattern acceptable in the norms of n-tier since originally I've used similar method also... :)

[DanInManchester]

I've used it and certainly I've asked the same questions as you within the last year or so and seen examples of both practices.

I'm somewhat new to the strong OOP model and I am still refining however on these more complex structure issues there seems to be fewer 'experts' around. Have you consulted with Microsofts Patterns and practices and looked at the www.asp.net examples as I'd hate to mislead you?

if you come up with a conclusion I'd be interested to hear your arguments for it.

[dee-u]

I'm essentially doing the same here only in this DTO it also has the methods.
If my DAL were to call the business methods then true this would be a circular method.

Your argument there is strong which tend to make me return to my original method, I'd probably post my modified solution (the one posted in my link) this week and let you tear it apart, thanks for the inputs, I appreciate them... :afrog:

[dee-u]

I've ran into discussions that tells the objects passed between layers should be lightweight, serializable and "ideally should only contain properties", what's your thought on this?

[DanInManchester]

I'd agree as that is why I did it in the first place.
But then I got thinking..... I don't really pass anything except between the DAL and the BLL and my objects are fairly light anyway. The UI uses the BLL rather than passing to it.

Current method of working
Dim member1 as member = new member
member1.load(Username)
txtMemberName.Text = member1.fullname
member1.fullname = "Joe Blogs"
member1.save

In my older approach
Dim memberController1 as memberController = new memberController
Dim member1 as member = memberController1.load(Username)
txtMemberName = member1.fullname
member1.fullname = "Joe Blogs"
memberController1.save(member1)

My current method just seemed a cleaner approach although it is slightly heavier when the objects go to the DAL.

Would like to hear someone elses opinion on this though.

[DanInManchester]

I've been doing some further reading and it would appear that the manager model is often prefered particularly where a service layer is involved , which makes sence.

However I have to say the domain model works better for me in a lot of cases maybe due to my misunderstandings.

For example :

I might have a readonly property that has some fairly complex logic behind it. This property may not be required sometimes so I would not want to populate it until requested.

If I use a DTO and get the property value, does the DTO have to have the logic within it to calcualte this or would it call a function in the controller class?

Either way it is going back to the domain model. So to stay with the manager model this property would have to have its own function in the manager class which is called separately which strikes me as odd.

How would you deal with this in the manager model?

In other cases it can work better. For example if I need to retrive a list my controller class can return an array of some description but returning such an array from a domain object is often out of context.

Any thoughts?

[dee-u]

I've attached the solution I'm currently working on in this thread (http://www.vbforums.com/showthread.php?t=388382) and I hope you could take some time to fiddle with it and provide me feedbacks on things I maybe doing wrong, things I've got to improve, etc...

Thanks in advance!

[techgnome]

Here's how we've got our new system set up.
The UI invoked the BLL, which invokes the DAL-Manager, and requests an object to use to talk to the DB. The CDC (custom data class) is passed to the DAL.

The DAL then gets a connection to the database from the DB Factory and calls the appropriate sp in the Database through the connection. I'm hoping this makes sense....

The BLL doesn't know or care what the database is.... in fact, even the DAL doesn't know anything about the DB either... it's simply fed a connection from the DB factory.

-tg

[dee-u]

Here's how we've got our new system set up.
The UI invoked the BLL, which invokes the DAL-Manager, and requests an object to use to talk to the DB. The CDC (custom data class) is passed to the DAL.

The DAL then gets a connection to the database from the DB Factory and calls the appropriate sp in the Database through the connection. I'm hoping this makes sense....

The BLL doesn't know or care what the database is.... in fact, even the DAL doesn't know anything about the DB either... it's simply fed a connection from the DB factory.

-tg

So you're also employing the Manager model? And your CDC is your DTO?

[techgnome]

Define DTO -

-tg

[DanInManchester]

A light weight custom business entity/class usually only properties e.g. a customer.
Used for passing business data between layers

[techgnome]

In that case... yes.... my CDC (or DTO, whatever) is solely passed back between the BLL and the UI. ... I take that back it also gets passed to/from the DAL manager for filling and/or updates.

-tg

[dee-u]

Define DTO -

-tg

Data Transfer Object

[dee-u]

I now have a chance to actually use different servers/tiers for the different layers I have been working. What I wish to know now is what should be the best or most appropriate method to pass DTO between different tiers. For instance, the BLL would be in a different server, the DAL would be in a different server, how can I interconnect those different tiers? A web service is the common scenario though it seem to be used in web applications, perhaps there is a more appropriate method with desktop applications?

I'll appreciate any info... TIA

[mendhak]

Still the best option, as it's the safest. Using a binary communication method would be more, how shall we put this, troublesome.