Is an Umbraco.Interfaces nuget package a good idea?
I frequently find myself coding purely to Umbraco Interfaces - Content Service, DataTypeService etc - all of which is interface based.
Would having extracting all of the interfaces to an Umbraco.Interfaces or Umbraco.Contracts NuGet be a good idea - so that development of that nature can all go into its own project and just be referenced from the main install. - I know I can do similar with Umbraco.Core but this would be much lighter. Perhaps I'm missing something or there's a better way?
The short answer is no. We don't intend to extract all of the interfaces or abstractions to an abstractions assembly. There are quite a few reasons for this, here's a couple:
We are still stuck in Legacy land which makes this process not as straight forward as you think
We have more than just interfaces, if we were to do this it would need to be done properly and carefully, we would need to extract all abstractions that people may need to use. I've gone down this road before during v8 dev and I will tell you that this is not an easy task once you start down the rabbit whole, especially because we are stuck in Legacy land. This would require us to re-factor quite a lot to make them properly abstract without references
I would like to understand the benefit you think you will be getting when you say
this would be much lighter
?
In v8, we will already be much lighter and we will have a better abstraction story, but v8 isn't going to be perfect and we will still have Legacy code maintain. As much as I'd like to make get rid of all of the legacy, we will simply not have enough time, we'll not wait so long to get other major versions out like we have done so over time this will get easier to do and maybe we can make that happen.
Thanks for the reply Shannon. I understand Legacy Land is a difficult place to leave (only too well) and I think that's probably enough of an answer - too hard to do quickly, time better spent on other things - natural progress may make it easier.
For some background, I guess I'm looking for best practices of how to structure work when coding against Umbraco. On other projects I tend to keep my interfaces in a separate assembly, code against those abstractions (again in a separate assembly) and (assuming I'm writing a controller) the only thing that goes into the main project itself is a very light controller. This keeps the changes that I make in the main project as light as possible and the dependencies are very clear.
Umbraco has its own way of doing things- its own best practices, and I understand the power of the package-architecture. Perhaps I should be trying to code everything as packages rather than the "minimally invasive" approach I'm trying to take now. But there's no clear reference material on creating packages/plugins I can find: a Google on the subject returns v4, v5! v6 and v7 articles, with much of the v7 feeling out of date, so I've fallen back to the "keep it simple" approach of putting as few changes into the Umbraco website project as possible.
I could also use the separate assembly approach but using Umbraco.Core in my code project. Somehow that feels wrong, because I'll have brought in an entire CMS core into a project that really only needs references to the interfaces, but the end product (what ends up on the published website) would be pretty much identical (possibly it would be identical - I should look at that more!)
Anyway, thanks for your time answering this - and thanks for Umbraco! #h5yr
Yes that is the thing, the end result is that you will have all of the references that UmbracoCms.Core brings with it in your end result site anyways.
That said, there IS something we can do to make things a little bit 'lighter', though the end result will always be the same, your resulting website will still have all of these dependencies.
We could/should easily have:
UmbracoCms.Core - is the Umbraco.Core assembly and it's dependencies
in v8 Core should have less dependencies than it does now (at least that is the hope for now but we'll see)
UmbracoCms.Web - is the Umbraco.Web assembly, and all legacy assemblies and dependencies, this will have more than Core
in v8 these legacy assemblies will not exist anymore
UmbracoCms - is the client files, transforms, views and all that other stuff that comes with it currently
That is something we can do and it would lighten things up for you
Is an Umbraco.Interfaces nuget package a good idea?
I frequently find myself coding purely to Umbraco Interfaces - Content Service, DataTypeService etc - all of which is interface based.
Would having extracting all of the interfaces to an Umbraco.Interfaces or Umbraco.Contracts NuGet be a good idea - so that development of that nature can all go into its own project and just be referenced from the main install. - I know I can do similar with Umbraco.Core but this would be much lighter. Perhaps I'm missing something or there's a better way?
Bump....
Perhaps I'll get the answer to this on the Umbraco training?
The short answer is no. We don't intend to extract all of the interfaces or abstractions to an abstractions assembly. There are quite a few reasons for this, here's a couple:
I would like to understand the benefit you think you will be getting when you say
?
In v8, we will already be much lighter and we will have a better abstraction story, but v8 isn't going to be perfect and we will still have Legacy code maintain. As much as I'd like to make get rid of all of the legacy, we will simply not have enough time, we'll not wait so long to get other major versions out like we have done so over time this will get easier to do and maybe we can make that happen.
Thanks for the reply Shannon. I understand Legacy Land is a difficult place to leave (only too well) and I think that's probably enough of an answer - too hard to do quickly, time better spent on other things - natural progress may make it easier.
For some background, I guess I'm looking for best practices of how to structure work when coding against Umbraco. On other projects I tend to keep my interfaces in a separate assembly, code against those abstractions (again in a separate assembly) and (assuming I'm writing a controller) the only thing that goes into the main project itself is a very light controller. This keeps the changes that I make in the main project as light as possible and the dependencies are very clear.
Umbraco has its own way of doing things- its own best practices, and I understand the power of the package-architecture. Perhaps I should be trying to code everything as packages rather than the "minimally invasive" approach I'm trying to take now. But there's no clear reference material on creating packages/plugins I can find: a Google on the subject returns v4, v5! v6 and v7 articles, with much of the v7 feeling out of date, so I've fallen back to the "keep it simple" approach of putting as few changes into the Umbraco website project as possible.
I could also use the separate assembly approach but using Umbraco.Core in my code project. Somehow that feels wrong, because I'll have brought in an entire CMS core into a project that really only needs references to the interfaces, but the end product (what ends up on the published website) would be pretty much identical (possibly it would be identical - I should look at that more!)
Anyway, thanks for your time answering this - and thanks for Umbraco! #h5yr
Yes that is the thing, the end result is that you will have all of the references that UmbracoCms.Core brings with it in your end result site anyways.
That said, there IS something we can do to make things a little bit 'lighter', though the end result will always be the same, your resulting website will still have all of these dependencies.
We could/should easily have:
That is something we can do and it would lighten things up for you
Thanks
That all sounds like I'm looking forward to V8 more than ever!
is working on a reply...