CODEWITHSUNDEEP
asp.netado.netdata-access-layern-tier-architecture
Ankush Jain
Ankush Jain

Reputation: 71

3 tier architecture issue

Nowadays, I have started working on 3 tier architecture but i have some doubts in my mind.

Generally we bind data control to a objectdatasource and call business object's function to perform select, insert, update or delete operation. I don't have any problem with this way.

But, My problem is that i have a login part that simply contains 2 textbox and 1 button and i created a business object whose property represent username and password then i called business object's function and that function in turn called data access layer's function to return a datarow containing userid from database if username and password are right....

so i think that it is not the correct way of working with 3 tier when you are not working with data controls...because here we are unreasonably calling function and function while we can access data even in code behind ...so please tell me that whether i am working correctly or not ?... or is there any better way of performing similar operation.

Upvotes: 1

Views: 534

Answers (2)

Erik Funkenbusch
Erik Funkenbusch

Reputation: 93464

That's the lazy programmer in you talking.

Three tier is an absolute. You can't have kinda-sorta-3-tier. That's not 3-tier.

3-tier is there to make code more maintainable in the long run, not reduce time to develop in the short therm. Use the tiers luke.

Upvotes: 1

Mike Hofer
Mike Hofer

Reputation: 17022

ASP.NET is odd when it comes to separation of data and business logic. MVC makes it easier, but you don't specify whether you're using it. We work around the issue as follows:

We build a static serialization class that is solely responsible for interacting with the database. It alone is responsible for invoking stored procedures. It returns instances of POCOs (plain old C# objects) that the serializer knows how to instantiate and populate with data from the database.

Now, the POCOs provide facade methods that forward calls to the serializer. For example:

public static Employee Load(int id)

would call the Load method on the EmployeeSerializer class. It wouldn't do anything else. But it lets pages work with Employee objects in a natural way.

Might not be right, but it's better than what we had before. Similarly, you call Employee.Save(), and the call is forwarded to the EmployeeSerializer.

This keeps all the stored procedure calls encapsulated in a single class. The business logic is encapsulated in the Employee class. And pages can just work with Employees.

Note that the business objects can live in a separate DLL from the database objects, but that tends to lead to problems with circular dependencies. Keep them in the same DLL, and put them in separate namespaces. But do separate them from the ASP.NET pages by placing them in a separate DLL together.

Upvotes: 1

Related Questions