Re: Which Layer to use

Responding to Arun...

Let's assume that there is a database with a single Customer
Table. Multiple users will access this database via a WebService.



I have


Presentation Layer

------------ ---------

Business Logic Layer

------------ --------- --

Web Service

------------ --------- --

Data Access Layer

------------ --------- -

Database

If you are going to use a RAD layered model, I am a bit confused about the location of the Web Service layer. I would expect web services to be associated with the Presentation layer. Are you suggesting that the user has a thick client where presentation and business live and that client talks to the DB via the Data Access layer through web services?

If so, one could argue that it really goes between Data Access and DB since the Data Access is really a logical entity that exists to convert Business Layer representation (e.g., a User object) into Database representation (e.g., Tables). IOW, if the client is thick, then I would expect that <problem-specific> conversion to be done on the client side.

That dichotomy segues to my main point. Web Services is really an implementation issue for supporting infrastructure. The other layers represent an organization of the logical design of the application, which would be the same if the app used a browser, GUI, or smoke signals. So I am not sure Web Services is an appropriate layer at all.

[In a non-RAD application one might well have a Web Services subsystem, but it would be a peer of a Data Access subsystem. But non-RAD applications are designed in a fundamentally different way from a systems engineering perspective so one doesn't use a RAD layered model at all.]

Whenever a record is opened by a users, their name and a timestamp is
stored in the table. Once a record is opened, users have a choice to
take ownership of that record ( a record can only have one owner).


If the user decides to take ownership of the record, the program will
have to check if the selected record already has an owner. If it
already has an owner (the owner may have been assigned while one user
was browsing the record), then the system should not allow anyone else
to take ownership of the record in question.

If it were simply an issue of one user at a time having write access, this would be a standard problem for DB mechanisms like two-phase commit. That would be primarily a Database layer issue, though the Data Access layer might need some notion of related issues like opening and closing DB transactions.

In your case, though, the ownership is persistent across DB accesses and transactions. In addition, the rules defining it are business policies that exist in the problem space (a single owner always) and need to be captured in the application solution. So the Business Layer needs to deal with those rules and keep track of the problem space notion of ownership. The ownership is recorded in the DB normally, but that is quite mechanical.

So when a user wants to take ownership the Business Layer has a specific sequence of steps:

(1) Check if the record is owned.
(2) If not, assign the owner
else, inform the user it cannot be owned

Now executing that business logic may require specific DB accessing techniques, such as locking the record containing the ownership field for (1) until (2) is resolved. That is the kind of processing (e.g., opening and closing update transactions) the Data Access Layer understands because it exists to access the DB.

So the solution is actually spread across two layers; one just separates the concerns by having the Business Layer deal with the business logic while the Data Access Layer deals with the DB access logic.



--
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.

Relevant Pages

  • Re: project references when building N-tier apps
    ... Extract business objects such as User into a third assembly ... which you then reference from both> Business.dll and DataAccess.dll. ... to call the data access layer and provide the above mentioned user.Save ...
    (microsoft.public.dotnet.distributed_apps)
  • Re: interfacing with data layer
    ... This mechanism can sit between the Business layer ... If you have an "app server" that also hosts your data access code, ... have web services as the transport between web server and app (business ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Classes, collections and data
    ... Being that it is a small app, putting the data access and business logic ... Normally I create a Business Layer that handles logic, calculations, ...
    (microsoft.public.dotnet.languages.vb)
  • Re: App Architecture: Typed Datasets, EntLib, Performance
    ... Deploying Business Entities ... and have typed datasets as the common ... Some say that they should not be filled by the data access ... layer, but rather should exist only in the business layer, which would ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: App Architecture: Typed Datasets, EntLib, Performance
    ... Deploying Business Entities ... and have typed datasets as the common library ... Some say that they should not be filled by the data access ... layer, but rather should exist only in the business layer, which would ...
    (microsoft.public.dotnet.framework.aspnet)