Microsoft.AspNet.FileProviders split into Physical, Embedded, and Interfaces

[Tratcher]

The Microsoft.AspNet.FileProviders package has been removed and replaced with:
Microsoft.AspNet.FileProviders.Physical
Microsoft.AspNet.FileProviders.Embedded
Microsoft.AspNet.FileProviders.Interfaces

See aspnet/FileSystem#48

[khellang]

Is there any consistency in naming of abstraction packages? There seems to be several variations, like Core and Interfaces... It would be nice if the abstraction packages was just *.Abstractions (since "core" might be misleading and "interfaces" doesn't really work with abstract classes) across the board, like Microsoft.AspNet.Http.Abstractions and Microsoft.AspNet.FileProviders.Abstractions 😄

[rondefreitas]

I would have to agree with @khellang on this one

[Eilon]

The pattern should be <whatever>.Interfaces when it's an interfaces package. There are other cases where "abstractions" doesn't necessarily mean "just the core interfaces" but rather a general abstraction of some concept.

[khellang]

In scriptcs we have *.Contracts, just to bring another name to the table 😉 I don't really care much what the name is in the end, just that it's consistent across 😄

[csainty]

Will it always be an interfaces-only package?
Does that stop you putting an abstract base class in there one day simply because you chose that name.

[davidfowl]

.Contracts isn't bad but we'd have to do it across the board and contract is so overloaded already.

[adamralph]

I vote for *.Abstractions.

[horsdal]

+1 to Abstractions

[uatec]

Indeed. *.Abstractions can include Interfaces and abstract classes and enums, etc.

Also, it might not be a contract between different systems (the abstract base classes, for example).

[wenhx]

+1 to Abstractions

[M-Zuber]

+1 to Abstractions

[blobor]

+1 to Abstractions

[khellang]

@Samvrie Either that or they just introduced another naming inconsistency. Now there's Core, Interfaces and Abstractions 😝

You could argue that they all make sense, if the different packages contains different things, but it'd still be nice, IMO, to go with the "lowest common denominator" (something that covers all) and stick with a single name.

[Eilon]

Hi folks, I'm starting an internal discussion on resolving this. I agree that being consistent has a lot of value.

[artganify]

@khellang As long as it makes sense and they keep it that way, devs will get used to it.

What I'm a little worried about is that namespaces like *.Interfaces might cause a dependency hell as things get bigger. For example a new base class get's introduced which is elementary for a new feature and directly relates to some components in *.Interfaces - but wouldn't really fit in there. So they would need to create a *.Interfaces.Core to make things meaningful again and bam, 2 dependencies.

@Tratcher What about just Microsoft.AspNet.FileProviders? Why not put abstractions, utilities etc., there? That won't hurt anybody as long as the package doesn't contain heavily infrastructure based stuff.

[Eilon]

@artganify BTW there's never a .Interfaces namespace - it's just the package/assembly name.

One reason we don't put these "abstractions" in the "short" (i.e. non-.Abstractions) package/assembly is that most people will use the main "short" named package that has both the default implementations, as well as a transitive reference to the .Abstractions package.

[justin-lovell]

In my opinion, the short name of Microsoft.AspNet.FileProviders should provide the abstractions. Those abstractions are completed and fulfilled by Microsoft.AspNet.FileProviders.Physical and Microsoft.AspNet.FileProviders.Embedded.

The "new project" wizard should refer to each specific implementation package where those "default" selections should be pulled in.

A GOD (Global Organised Description) package if you will call it that? :)

[adamralph]

In this particular case, yes, but for a general pattern, I'd say *.Abstractions is a good fit.

Even though, in this case, the implementation packages have their own distinguishing names since there are two of them, it wouldn't add much noise for the abstractions package to be named *.Abstractions.

[danielmarbach]

+1 for .Abstractions

[damianh]

👍 for consistency and 👍 to @justin-lovell

Am really very meh about *.Abstractions etc for a naming convention. Are we just talking about the package or the dll(s) too?

[Eilon]

@damianh it would be package + assembly name, but not namespace name. As such, you'll almost never see it - just in the project.json file.

[LordZoltan]

The use of reference assemblies merging into a root namespace to create a wider whole is something that, to me at least, makes perfect sense.  As has been said, you won't really ever know it's there, unless you're specifically developing your own provider.
Equally, in keeping with 'take only what you need' approach to references, especially where multiplatform needs to be considered, sticking the abstractions in their own package makes sense.
Abstractions here is an important term - not just interfaces, but (potentially abstract) bases too.  If you start mixing in enums and other ancillary types used by those abstractions, then an argument could be had that the root package/assembly is the place for them.
Otherwise, a .Abstractions package/assembly gets my vote.
On 28 Apr 2015 11:32 pm, Eilon Lipton notifications@github.com wrote:@damianh it would be package + assembly name, but not namespace name. As such, you'll almost never see it - just in the project.json file.

—Reply to this email directly or view it on GitHub.

[Eilon]

OK after reviewing the discussion here and a long and healthy team discussion, we settled on using the .Abstractions naming pattern, along with a few other relevant tidbits.

The full details are below, and expect to see some of the changes start to roll in this week.

---

There are generally two scenarios that we target:

1. App builders
2. Library builders

(They’re often the same people, but the scenarios are different.)

The solution is:

1. For app builders we keep doing what we’ve done quite well: for the package that an app will most likely reference, use the “main” package name (e.g. EntityFramework, Microsoft.AspNet.Mvc, Microsoft.Framework.ConfigurationModel).
   • This is the majority of scenarios, and it has the best discoverability
2. For library builders, where appropriate, have a *.Abstractions package that has no concrete implementations of the key interfaces. It may contain utility types, extension methods, etc.
   • This allows libraries to minimize their dependencies, and to avoid inadvertently coupling to concrete implementations
3. For library builders, when the "main" package name is a meta-package or otherwise roles in many areas of functionality, can also have a *.Core package that contains the primary implementation of the abstractions.

---

So the most common patterns are:

Just one package to rule it all:

• Qqq

Package that has abstractions:

• Xxx.Abstractions --> used if you are only consuming or implementing an Xxx concept, like a lib does, but aren’t "adding it to an app"
• Xxx --> used if you are adding Xxx to an app, contains the standard implementations of the Xxx concept

Package that has "core" features, plus optional features, plus a meta-package to bring everything in for convenience:

• Yyy.Core --> contains the bare-bones standard implementations of the Yyy concept, used if you are adding Yyy to an app "the hard way"
• Yyy.FeatureA --> contains a layered-out implementation of an optional feature
• Yyy.FeatureB --> ditto
• Yyy.FeatureC --> ditto
• Yyy --> rolls Core+A+B+C into a convenient dependency, used if you are adding Yyy to an app "the easy way"

And finally a package that use all the patterns together:

• Zzz.Abstractions --> used if you are only consuming or implementing a Zzz concept, like a lib does, but aren’t "adding it to an app"
• Zzz.Core --> contains the bare-bones standard implementations of the Zzz concept, used if you are adding Zzz to an app "the hard way"
• Zzz.FeatureA --> contains a layered-out implementation of an optional feature
• Zzz.FeatureB --> ditto
• Zzz.FeatureC --> ditto
• Zzz --> rolls Core+A+B+C into a convenient dependency, used if you are adding Zzz to an app “the easy way”

[khellang]

Nice writeup, @Eilon!

❤️ that you landed a solution. Whether all people agree on the naming or not, at least you've settled on a consistent approach, and that's all we can ask for 😄

[Eilon]

You're welcome! 😄

[robertmuehsig]

Just a small question regarding "one Package to rule it":
The xxx Packages will have a dependency to the underlying xxx.Abstraction Package, right?

[Eilon]

@robertmuehsig yes, generally all Xyz[.*] packages would depend on Xyz.Abstractions.

[horsdal]

👍 Good result