What are the pros and cons of directly exposing a Table/View entity class to the client?

Question

I'm developing a multi-tier application. We separate our project into three logical layers: client, service and data access. However, almost all methods in the service layer don't do anything except returning table/view from DAL to the client and then the client continues processing data. More than 50% of the returned data is bigger than it really needs to be. For example the client needs a username and an email-address but the service layer returns way more data. This is the coding standard in my team. I tried to change this by shaping classes that return what the client really needs but they wanted me to change it back after I had done it.

I'm curious what are the pros and cons of doing things that way?

Answer 1

Let's say we have a table of users which stores:

1. Id,
2. First name,
3. Last name,
4. Email,
5. Address,
6. City,
7. Phone, and
8. Mobile

And let's assume that our client needs the following information, at separate points:

1. User name,
2. User name and email,
3. User postal address, and
4. User phone number

We can obviously develop a set of functions (in the service layer) like:

• getUserName(id), which would return first and last names,
• getUserNameAndEmail(id), which would return first and last names, plus email,
• getUserPostalAddress(id) ..., and
• getUserPhone(id) ...

or we could develop just one function:

• getUserInformation(id), which would return all user information regardless of what is needed where.

There isn't any obvious technical reason to choose one method over the other as both have clear merits: The first way, we only transfer the data we need from server to client, but the second way we only build one function and reuse it every time we need any user information.

It's a question of data volume and bandwidth. If the client and the server are connected via the internet, and our data are large then we should probably choose the first method, as we don't want the customer to experience any unnecessary lag. But if the client and the server are on a local network, or any high speed network then the second method is probably the best way to go, as we gain some development time.

Of course our data may be extremely large, and the first method be preferred even on a local network, so to clearly understand why your development team chose their practices you must first understand the data you are dealing with. Finding (asking for) some concrete metrics would be a good first step. You will most probably discover that your fat data solve more problems than create.

Answer 2

Pro's of exposing entities directly to a client

• Little overhead in translation between rdbms structure and entity structure and thus lightweigth solution
• It provides a chunky interface which is good for network throughput/efficiency
• Easy serialisation of data structures
• Provides a means of optimistic concurrency (offloads the database concurrency checking and locking)
• Enable cacheing of items for efficiency (at least using EF dbcontext)

Con's

• When persisting values, there is no way to check wheter the instances have gone through validation before submitted for persistence
• Little gained by exposing entities instead of using a database connection from your client (e.g to manage concurrency)
• There can be more than one version of your client out there so business rules might vary which coulod create problems for your database schema
• change tracking and conflict resolution will require more effort than using a more granular option (field based changes)

Cheers, Carlo

Answer 3

This would very subjective but below are some points to consider.

• Data has a particular structure. In typical RDBMS this structure is relational.
• A data structure should be chosen based on what sort of operations/procession that your application logic needs to do on the data.
• If there is difference between the data structure the processing engine of your application and data structure that your persistence layer uses, then you will need some intermediate layer (service or whatever you want to call it) that will act as the data structure transformation layer. This layer should not do anything else other than this mapping between data structure.

In your particular case you need to ask the question, does the 2 data structures differs significantly, if yes, the you need that service layer, if not then you don't.

Answer 4

If the clients request many different groupings of data and if you don't give them the ability to request the data they want through some type of query language, constructing classes to return various data combinations will be a never ending battle. For every entity the possible number of combinations can be absolutely huge if the number of fields is more than a few.

So if the classes created only serve to limit the amount of data returned then the work probably wouldn't be worth it. Unless of course there are very common data groupings that are requested often by many different clients.

Now if you want to simply limit the amount of data returned you could create classes that lazy load the fields as they are requested. Depending on architecture this could be beneficial. But in many cases lazy loading actually hurts overall scalabilty and performance.