Conceptual dependencies instead of explicit library dependencies

[wallymathieu]

• Dependency injection container: Func<Type, Object> or Func<Type, string, Object> vs System.IServiceProvider

  • Are concrete types automatically registered?
  • Can you have multiple things of the same type registered?
  • Does the order of registrations matter?

• Logging see logadapter vs logging abstractions
  a logging abstraction could be something like Action<Exception, string, object[]>, Action<string, object[]> (i.e. where you have the choice to plug in whatever)

  • is the string a template? are the objects added as context regardless of the string?

• Parameters and configurable options : why is a POCO class not enough? Could Func<Poco> fill the same role?

[wallymathieu]

You could look at the way some frameworks force you into use them for your POCO objects since they color what kind of structures you can use.

[wallymathieu]

Another example of implicit dependency is when you use ORM that has a specific behavior related to how it implements LINQ. Lazy loading or not? Possible to map link-tables as many to many in a nice way (or does the ORM require you to have a link-table-class)? How is it possible to use ids (custom ids or not)? Is it possible to use immutable POCO with ORM?

[wallymathieu]

Most logadapters define errorlevels, but these are not standardized other than that they usually are named something like "error", "err", "ERROR", "info", "INFO", "Information" et.c. The int values of the enums are then of course not normalized...