it:ad:patterns:minimal_dependency_cardinality

IT:AD:Patterns:Minimal Dependency Cardinality

Summary

Writing portable code – code that can be reused in as many different scenarios as possible – is not difficult. It just needs planning up front (it's much much more costly trying to refactor it for portability later).

With most developers working on websites, where they have at their disposal the totality of the .NET framework, it's easy to forget that there are other frameworks versions to address:

  • Client Version (trimmed so that ClickOnce apps don't have to download 200Mb of Framework first…)
  • Siliverlight (80% of the .NET Framework in 4Mb)
  • Micro stuff I've never looked at personally.

The point is, to make code portable, it has to work on the lowest common denominator.

Most assemblies don't need all that power (if you're not using System.Web or Entity Framework, it probably will work just fine if the Framework it is compiled against is switched to the Client Framework).

If you are not actively using, and therefore really need, syntax and features that are only available in a later framework (eg: Code Contracts), consider using .NET35 (which is of course .NET20) to .NET40.

This is a controversial suggestion, as there are pros and cons to this.

On one hand, you are making your code more portable, as it can be installed on more platforms that do not have the framework available (and more clients who refuse to update their hardware), but on the other, you are not pushing yourself to learn new concepts that would be beneficial to the same clients (eg: Code Contracts is one such benefit, providing safer code).

It's a choice. Personally, we have gov and bank clients who still require us to develop on .NET35…so XActLib/ has as many assemblies as possible that still use that framework.

Whether you choose to use .NET35 or .NET40, is – in the big scheme of things – not that important. What is important is reducing the cardinality of each assembly. That's a fancy way of saying that any assembly you create should have References to as few other assemblies as possible.

By default Microsoft creates new assemblies with references to System.Data and System.Xml – both of which in 90% of cases you don't need (System.Xml is needed for Serialization, and therefore is mostly only needed up in the Distributed Service Layer, and System.Data is a bomb that should be removed from every assembly bar Repository Services in Infrastructure (Data) Layer assemblies (you really, really don't want to allow developers to use System.Data – and therefore drag a really heavy infrastructure requirement right up into the Application, Domain, Distributed Services, or UI layers.

For this reason, the first step after creating a new assembly and adding it to your application is strip your assembly References down to the bare minimum, and only grudgingly adding References back in.

For example, the App.Back.Domain.Persistence's responsibility) so System.Data should be removed.

In addition, the App.Back.Domain Layer is not dealing with serialization (that's the App.Back.Application.Facade's responsibility) so System.Xml can be removed.

  • /home/skysigal/public_html/data/pages/it/ad/patterns/minimal_dependency_cardinality.txt
  • Last modified: 2023/11/04 03:29
  • by 127.0.0.1