Attention: We are retiring the ASP.NET Community Blogs. Learn more >

Exposing your business logic layer

One of the main reasons for designing software in several layers is to reduce the impact that the changes in one layer have in the upper layers. For example, you keep all your SQL code in a Data Access Layer, and when your schema changes, you just need to change that layer and not the upper ones.

Even if we all agree this is a good design, is pretty common to make your UI layer use your domain object model. If you need to access the name of a customer in an Invoice, you write Invoice.Customer.Name. By doing this, you are exposing your internals to the UI layer. What happens if you need to change the place where the Customer Name is in your model? You can do two things. Break the interface by removing the Name property in the Customer or somehow get the Name of the Customer in the property, by accessing other object to retrieve it. None of them are a good solution.

What if instead of exposing your object model you have a way to give the client the data it needs, structured the way it needs it? If you need to display an Invoice in a web page, you should return a header and a set of Invoice Lines, probably in two different objects (a InvoiceHeader instance and a InvoiceLine collection). In this way, the UI programmer job will be much easier, as it has only the data he needs and it will be much easier to bind, as you have a tabular view of the data.

Also, working this way is much better for exposing your middle tier as web services. You can focus on the data the consumer needs, instead of exposing your middle tier components in some weird way, omitting the fields you don't need, etc.

I'm not saying this is easy to do, but it seems a cleaner solution. Am I missing something?

 

4 Comments

  • Sure. YOu have an simple class that you can pass to the ui or you can pass to the business layer. The business layer can populate it, process it, get data from it to send back to the database, etc.. But when you send that object to the ui, you are not exposing your business layer. Is that what you are talking about?

  • This is what he is talking of, and - sorry -- it is pretty dridiculous. I mean, business classes are PRETTY stable in their code, and - any change ANYWAY ripples up. He is adding an additional layer which (when not needed) just blows up the code AND does not really handle any problem, IMHO.

  • Andres,





    I don't think that you are right. If Customer.Name is a public property, it is part of the interface. You shouldn't easily change the interface, and even if you do, you shouldn't complain why the client doesn't work anymore!


  • Actually, I kind of agree. My company exposes many bits of functionality to a wide variety of interfaces (both IInterfaces and interfaces products alike). We built a very robust multi-function data layer into Oracle logic that provides WAY more information than any individual interface requires. Rather than provide ALL data to ALL interfaces or build a custom data layer for every interface, we built another thin layer for each interface that provides only the data that interface needs and no more.





    As for "upstream ripple", sometime this solution helps and sometimes it doesn't. It really depends a lot on what gets touched and what implications it has on different interfaces.

Comments have been disabled for this content.