Link to home
Create AccountLog in
Avatar of ozencozturk
ozencozturk

asked on

does databinding fit in 3 layered architecture?

Lately i have been checking out some examples about databinding in .NET 2.0 and WPF. However i have a hardtime finding a way if/how i can use databinding with 3 layered architecture.

As I know of, the presentation layer is used for interacting with user(getting,validating,listing I/O)  and sending it to business object layer for applying business rules/verification. However when we use data binding, that step is skipped and presentation layer interacts directly with data access layer. Is it possible to use data binding yet still maintain 3 layered architecture?
Avatar of p_davis
p_davis

if you send a business object or dataset to a client. it doesn't have to have any knowledge of the database or, even of the services that process them-- this still is in line with 3 tier (i believe) and you can still use databinding to these "temporary" sets of data, manipulating them and sending back across the tiers.
Absolutely!  You can use databinding with multiple layers!

In an N-Tier scenario, your Presentation layer should only have a reference to your Businsess layer,
and should not directly communicate with the Data Access layer at all.  The Business layer should have
a reference to the Data Access layer to retrieve the type of information it want.  The Data Access layer
should retrieve the requested data from the data base.

Any databinding that would occur should never occur between the Presentation layer and the Data
Access layer, but should always be between the Presentation layer and the Business layer.

VBRocks
MS MVP
SOLUTION
Avatar of joesthebighmoe
joesthebighmoe
Flag of United States of America image

Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Avatar of ozencozturk

ASKER


Ok then this is what it should be like? Consider a form with a datagridview named dgvCustomers and 2 textbox objects txtCustomerID and txtCompanyName, and 2 buttons named "new" and "save".  (using northwind data set)

I have used this approach so that binding source isnt exposed to Business Object Layer.





//User interface layer
namespace UIL
{
    public partial class UICustomer : Form
    {
        BOL.BOLCustomer bolCustomer = null;
        BindingSource bsCustomers = new BindingSource();
        bool addingNew = false;
 
        public UICustomer()
        {
            InitializeComponent();
            bolCustomer = new BOL.BOLCustomer();
            dgvCustomers.DataSource = bsCustomers;
 
        }
 
        private void UICustomer_Load(object sender, EventArgs e)
        {
            DAL.NorthwindDataSet.CustomersDataTable customerDataTable = bolCustomer.GetCustomers();
            bsCustomers.DataSource = customerDataTable;
 
            txtCustomerID.DataBindings.Add("Text", bsCustomers, "Customer ID");
            txtCompanyName.DataBindings.Add("Text", bsCustomers, "Company Name");
        }
 
        private void btnAdd_Click(object sender, EventArgs e)
        {
            addingNew = true;
            bsCustomers.AddNew();
        }
 
        private void btnSave_Click(object sender, EventArgs e)
        {
            bsCustomers.EndEdit();
            DataRowView currentRow = (DataRowView)bsCustomers.Current;
            DAL.NorthwindDataSet.CustomersRow currentCustomerRow = (DAL.NorthwindDataSet.CustomersRow)currentRow.Row;
 
            if (addingNew)
            {
                // Add New
                addingNew = false;
 
                try
                {
                    bolCustomer.AddCustomer(currentCustomerRow);
                }
                catch (Exception exception)
                {
                    MessageBox.Show("New record error" + exception.ToString());
                    bsCustomers.CancelEdit();
                }
            }
            else
            {
                // save existing
                try
                {
                    bolCustomer.SaveCustomer(currentCustomerRow);
                }
                catch (Exception exception)
                {
                    MessageBox.Show("Saving error" + exception.ToString());
                    bsCustomers.CancelEdit();
                }          
 
            }
        }
    }
}
 
// business object layer
namespace BOL
{
    public class BOLCustomer
    {
        DAL.NorthwindDataSetTableAdapters.CustomersTableAdapter customersTableAdapter = null;
        
        public BOLCustomer()
        {
            customersTableAdapter = new DAL.NorthwindDataSetTableAdapters.CustomersTableAdapter();
        }
 
        public DAL.NorthwindDataSet.CustomersDataTable GetCustomers()
        {
            DAL.NorthwindDataSet.CustomersDataTable customersTable = new DAL.NorthwindDataSet.CustomersDataTable();
            customersTableAdapter.Fill(customersTable);
            return customersTable;
        }
 
        public void AddCustomer(DAL.NorthwindDataSet.CustomersRow newRow)
        {
            // validate newRow apply business rules
            //.................
            // update in data access
            customersTableAdapter.Update(newRow);
        }
 
        public void SaveCustomer(DAL.NorthwindDataSet.CustomersRow row)
        {
            // validate row apply business rules
            //.................
            // update in data access
            customersTableAdapter.Update(row);
        }
    }
}

Open in new window

I understand the benefits of using Business Objects instead of DTO (The scope issue is true, i have to link DataAccessLayer in UserInterfaceLayer in order to use types which is a bit irritating), but i think that DTO has its own benefits in my case. I'm working on a relatively small project and I don't want the burden of Creating/selecting/updating all business objects and filling form controls through code. However i still want to maintain an architecture and don't want the code look like a jungle
You might be right. If an application is just a basic "Create, Read, Update, and Delete data from a database " kind of application, then business objects might be overkill. For this kind of basic programming, using a dataset to complete this CRUD-oriented design might be fine.
-Cheers,
Joe
joesthebighmoe,

First of all, I don't mean to sound contentious, so if I do sound that way, I apologize.

I am just curious about something you mentioned,

>>"when you step into the realm of truly benefiting from an n-tier approach you would also benefit from
>>an business object approach which would never have data objects being databound to the
>>presentation layer."

When you say "data objects", do you mean DataSets/DataTables, etc., are you referring to traditional class business objects, or both, etc?

My question is, if you don't think that the business layer's purpose is to provide business objects that
can be bound to controls, then what's it's purpose?  How is it suppose to retrieve data, apply business
logic, handle errors, etc?

Here is a link to a video from Miscrosoft about building N-Tier applications (VS 2008, but you can still
benefit from it).  In this video, instead of creating class business objects (which can be very extensive),
they utilize a DataSet, and EXTEND it.  Though EXTENSIBILITY, ADO.NET rocks all over traditional class
based object archticture, because it can be extended to do everything traditional classes can be
designed to do, and a lot easier!  It supports validation, error handling, advanced filtering and sorting
(which you'll program all day to try to accomplish), etc., to name a few...

Here's the video - just check it out...

Live From Redmond: VB9  Building N-Tier Applications  

http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032332486&EventCategory=5&culture=en-US&CountryCode=US


VBRocks

VBRocks-
Don't sweat it. ;-)
>>When you say "data objects", do you mean DataSets/DataTables, etc., are you referring to traditional >>class business objects, or both, etc?
Yes, I mean DataSets/DataTables, etc

No, I would never define the business layer's purpose as providing objects to be bound to user interface controls. On a phone system that does not even make sense. I would say the business layer's purpose is to abstract the business.

<<Here is a link to a video from Miscrosoft about building N-Tier applications>>
You'll forgive me, for this is a completely separate discussion, but I stopped looking to Microsoftfor design solutions ages ago.  For a basic CRUD application things like "validation, error handling, advanced filtering and sorting" might pique my interest, however, I have not worked on a basic data-centric application in a long while.  Though because I am a good sport, and a geek, I will check out the video you posted, I promise!  ;-)
-Joe

Well, I have studied N-Tier application design.  The most recent book I read was (not a Microsoft book)
by Deborah Kuratah, and was called "Doing Objects in Visual Basic".  I thought it was a pretty good
book, however much of what she laid forth could be accomplished by extending ADO.NET, much easier.

And essentially, the primary purpose of the Business Layer in a data centric application is exactly that:
Retrieving the data from the Data Access Layer, and creating objects that represent that data, and
apply all of your business logic to that data (such as validation, calculations, error handling, etc.).  The
Business Objects in the Business Layer can be directly bound to controls in the Presentation Layer.

No validation or error handling, etc. should be performed by the Presentation Layer at all:  all it does is
present data, that's it.  When the user enters something incorrectly, it is validated in the Business Object,
not by the Presentation Layer or the Data Access Layer.

VBRocks


I disagree with nothing you typed.
I thought you felt it wasn't the business layer's purpose to provide objects to be bound to user
interface controls.

My apologies, I guess I misunderstood you.





"To be bound" is probably our disconnect. Binding has nothing to do with business. Thus I would say the business layer does provide business objects, period. I don't care if they are bindable or not, that's a presentation concern.  Furthermore, you are talking about a data-centric application where the purpose of the application is to put data in and pull data out of a database. I tend to work on applications where the purpose is more geared towards the representation of a business. The maintenance of the data is secondary to capturing the business in software.
Oooh...  Now I gotcha!  You're right on the binding issue.

Also, I'm not in disagreement with your statement about capturing the business in software at all.  I think
that should be the core architecture of the Business Layer.  But data is part of every business, and will
end up being represented when you capture the business.

I think ozencozturk could probably use a little more help though.  Do you have any suggestions for him?


Ultimately I will defer to you.
Providing efficient and simple data maintenance is not my forte.

When I do have to work on data maintenance, I tend not you use any DTOs still. For example, if I need to edit a Person object's name. The BL would provide a collection of Persons. The user would choose to change a specific Person's name. The Person would have a Name object (immutable value object). The GUI would display the properties of the Name object and allow the user to make changes. The GUI would create a new Name Candidate object and ask it if it is valid. If so the GUI would call a service for updating names and pass in the person and the new name candidate.  
As you can see, I am a pretty straightforward OO developer.
ASKER CERTIFIED SOLUTION
Link to home
membership
Create an account to see this answer
Signing up is free. No credit card required.
Create Account
Impressive discussion, really helped my understanding of the concept of business objects and data objects. The final example VBRocks send is a nice one as well. (Although i'm gonna stick to Typesafe datatables & that requires some change on the logic i think)