Freigeben über

Resources for n-tier application patterns

  • Artikel

Due to my involvement with data access/ object-relational technologies, I often get questions about how to build a 3-tier app and the guidelines around it. Some are specific questions in the context of an application while others are attempts to cut through a fog of buzzwords - SOA, aspect-orientation etc. In response, I have a small compilation of links and resources that provide some guidance in this area - specifically for .NET applications.

General resources on architectural patterns and related best practices:

Overall starting point:https://www.microsoft.com/resources/practices/default.mspx
Enterprise library: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/entlib.asp
Data access: https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/daab.asp
Smart clients (assuming that your “presentation layer” is a smart client): https://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag/html/SCAG.asp

To address common confusion around use of different serialization technologies and the role of web services, you may find the following useful:

https://blogs.msdn.com/richardt/archive/2004/07/21/190742.aspx https://www.microsoft.com/indonesia/msdn/indigofaq1.asp

In general, I am personally not a fan of pure architectures and buzzword compliance. Having worked on apps on challenging schedules and in challenging legacy contexts, I tend to take a more pragmatic approach to multi-tier application design. In general, it is a good idea to not tie your presentation layer to the database and ideally you would have a business objects that encapsulate behavior beyond what is reasonable in database. But having said that, you may have small and simple apps that can be developed much faster with a presentation layer that is logically not very far from the underlying relational model. Likewise, you could take care of a number of validations in the database if they are related to the long term lifecycle of the data and independent of a particular application. There are still some guidelines to follow and rules of thumb to think about:

- If you want data quality assurance, you better seriously think about it in the database tier. Data is often shared between apps and often outlives applications that produce or consume it.
- If you have complex business logic that changes over time or is application specific, you may find it easier to handle it in business objects rather than the database.
- For trust, scale and separation of concerns, you may want to keep the presentation layer reasonably independent of the business objects and certainly the database. You could invoke appropriate methods on the business objects from the presentation or workspace tier instead of shipping business objects from the mid tier to the client.

There are plenty of good books (e.g. Martin Fowler's Patterns of Enterprise Application Architecture) that document the patterns. Take a look at them and see which ones apply.

Comments