Press Ctrl / CMD + C to copy this to your clipboard.
This post will be reported to the moderators as potential spam to be looked at
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?
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
this would be much lighter
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:
That is something we can do and it would lighten things up for you
That all sounds like I'm looking forward to V8 more than ever!
is working on a reply...
Write your reply to:
Image will be uploaded when post is submitted