object served for communcation between business layer and presentation layer

Question

This is a general question about design. What's the best way to communicate between your business layer and presentation layer? We currently have a object that get pass into our business layer and the services reads the info from the object and sets the result into the object. When the service are finish, we'll have a object populated with result from business layer and then the UI can display according to the result of the object.

Is this the best approach? What other approach are out there?

Answer 1

Domain Driven Design books (the quickly version is freely avaible here) can give you insights into this.

In a nutshell, they suggest the following approach: the model objects transverse from model tier to view tier seamlessly (this can be tricky if you are using static typed languages or different languages on clinet/server, but it is trivial on dynamic ones). Also, services should only be used to perform action that do not belong to the model objects themselves (or when you have an action that involves lots of model objects).

Also, business logic should be put into model tier (entities, services, values objects), in order to prevent the famous anemic domain model anti pattern.

This is another approach. If it suits you, it depends a lot on the team, how much was code written, how much test coverage you have, how long the project is, if your team is agile or not, and so on. Domain Driven Design quickly discusses it even further, and any decision would be far less risky if you at least skim over it first (getting the original book from Eric Evans will help if you choose to delve further).

Answer 2

We use a listener pattern, and have events in the business layer send information to the presentation layer.

Answer 3

It depends on your architecture.

Some people structure their code all in the same exe or dll and follow a standard n-tier architecture.

Others might split it out so that their services are all web services instead of just standard classes. The benefit to this is re-usable business logic installed in one place within your physical infrastructure. So single changes apply accross all applications.

Software as a service and cloud computing are becoming the platform where things are moving towards. Amazons Elastic cloud, Microsofts Azure and other cloud providers are all offering numerous services which may affect your decisions for architecture.

One I'm about to use is

Silverlight UI

WCF Services - business logic here

NHibernate data access

Sql Server Database

We're only going to allow the layers of the application to talk via interfaces so that we can progress upto Azure cloud services once it becomes more mature.