Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries

Framework Design Guidelines teaches developers best practices for designing system frameworks and reusable libraries for use with the Microsoft .NET Framework and WinFX. This book focuses on the design issues that directly affect the programmability of a framework, specifically its publicly accessible APIs.

Chapter 4 of Framework Design Guidelines, titled "Type Design Guidelines," presents guidelines that describe when and how to design classes, structs and interfaces. In this chapter, Abrams and Cwalina divide types into four groups and discuss the do's and don'ts of type design.

Jumping to NHibernate

Problem Definition
Domain objects form the backbone of any application. They capture the core data model from the database and also the business rules that apply to this data. It is very typical for most subsystems of an application to rely on these common domain objects. This means that the closer the domain objects map to the data model in the database, the easier it is for the application developers to understand and use them because they mimic real-life "entities" and "relationships" as represented in the database.

If domain objects are not separated from the rest of the application, we end up with duplication of code everywhere. Similarly, if domain objects are not separated from the persistence code, we face situations where any subsystem using the domain objects also knows and depends on the persistence objects. And, any change in persistence objects affects the entire application, hence a bad design.

Solution
One way to achieve the above mentioned goals is to separate the domain objects into a separate subsystem and let the entire application use them wherever it needs domain data. Additionally, we should separate domain objects from the persistence code. This double-decoupling allows us on one hand to avoid code duplication and on the other to hide the persistence details from the domain objects and make it more flexible in case it needs to change. The domain objects and the rest of the application is totally unaffected whether the data is coming from a relational database or any other source (e.g. XML, flat files, or Active Directory/LDAP).

In separating the persistence logic from domain objects, we ensure that the domain objects have no dependency on the persistence code. This allows the domain objects to become available in environments where we don't even want to expose our persistence code.

How to achive it:

Domain Objects Persistence Pattern for .NET

Use of NHibernate by Justine Gehtland

Use of NHibernate by Justine Gehtland - Part 2