best way to reference business objects from presentation layer..?

Question

I want to develop an enterprise app that includes a WindowsForms presentation layer, middle-tier components for business logic and data access, and a MsSQL Server database. Middle-tier components should contain some business objects and will be called from presentation layer using .NET Remoting. Whitch is the best way (and why) to reference these business objects from presentation layer?

• A) Create class library project, implementing business objects. Reference this project from presentation layer and middle-tier layer.
• B) Create interface library project defining business objects. Create class library project implementing interfaces. Reference class library project from middle-tier layer. Reference interface library project from presentation layer.
• C) Create separate class library projects for middle-tier and presentation layer. Reference corresponding project from presentation layer.

Answer 1

There's probably no clear cut and definite answer to this, it depends on what you are doing.

• A will often be good enough in many cases. For small 'single app' projects there isn't really any reason why you can't just reference the business object library directly from both UI and BL layers. It's certainly the simplest, and sometimes simplicity is best.

• B is probably the "best", You'll be abstracting your actual implementations away so future changes are possible without breaking contracts, and unit testing is easier if you have interfaces. The other advantage of this is that you won't find it too difficult to switch from B to C in the future if you find it necessary.

• C is probably overkill in most cases. That said, on larger projects you may find it necessary. I've worked on large client-server n-tier applications that have had as many as three independent sets of data objects. One set used in the DA layer to map and store in the database. A second set in the business logic and network layers for processing and passing over the network, and the third set in the client for binding to the UI. It's worth considering using interfaces for C as well because of the abstraction advantages.

All in all, without knowing exactly your application domain or scope - B is a good starting point.

Answer 2

I've seen all three approaches work well.

What can sometimes be good is to start with A, then as the complexity increases move to B, then C.

In simple projects the "business objects" can be included in the same project as the presentation and persistence tiers - although it may seem heresy, defining the objects using different namespaces can provide enough separation between the "layers".

You may want to reconsider use of .NET Remoting - WCF is by far a better technology and much easier to use.