A couple of questions on multiple screens. (.NET)

Prologue

It is unlikely that this article will be included in someone's favorites, since it is not an article as such. There is no collection of wisdom for beginners. There is not a single line of code here. There are no pictures to attract attention. Rather, this post is questions and thoughts out loud to a simple programmer of an outsourcing company. Therefore, it will be somewhat reminiscent of a cut and glued together dialogue (well, in this case, rather, a monologue) from a smoking room in the office of an IT company. Probably many of the questions I can answer those developers who are very familiar with. NET CMS Orchard and Umbraco . I would like, just in case, to appeal to your intelligence - do not arrange sacred wars here, please. After all, you yourself have long understood that there are pros and cons everywhere and, moreover, with the existence of two popular solutions to one problem, their ratio is approximately equal to one. Also, I would like to apologize for the resulting towel.

As for one project, we made our CMS

In 2010, my partner and I went to the project to a client who, due to his obligations (we did not recognize the details), could not use third-party components. In view of the fact that Microsoft itself implements third-party open components in its products, the client clarified that it is possible to use the information provided in Microsoft products. The client had its own IT department, where a preliminary analysis was conducted and even some work was started. We connected almost at the very beginning of the cycle. Their IT department did a very good job on the base, using their previous work. This step was justified, since the new system had to be closely integrated with their old one. And the old system is, in fact, the base. Frontend and DAL were completely erased and rewritten. The base was finally fully integrated with the old product. During the whole period of development, several types of used technologies were replaced and further - several versions as a result of established technologies. There was a lot of work, but like all self-respecting programmers, we worked on “zashib”, and not on “fall off”. Every day, people thought about how to improve modularity, how to improve the assembly process. Slowly introduced and Agile practice, and the practice of prototyping. This may seem ridiculous to some. But who had complex customers with an outdated system - they will understand me. Any innovation is accepted, if not with hostility, then at least passes through a filter of aggressive criticism. Returning to our product, we provided a lot of what seemed to us to be new. They used orthogonal ideology, everything in the project was a widget. Everything was configured through the base. Widgets themselves were a plugin (no, not MEF ¹ , a regular IoC Unity ² container from EntLib ³ ). Further and AOP began to use. Everything was done without regard to the existing CMS . Of course, it was silly not to stare at existing solutions. But in our context, everything was logical. Initially, the product as a CMS and did not appear. This client smoothly added details to the requirements. As always. Of course, we were ready for this. It always happens because there were no problems with financing or reassessing the budget. I just specify that we started to turn the product into a CMS by accident. Due to the revision of requirements, a retrospective of events and an attempt to see the product from the point of view of the customer, in order to foresee his wishes. The usual practice of DRY , introduced by Agile ⁴ process, orthogonality, an attempt to automate everything and get configured through the base or configuration files, a good implementation of the assembly shop on TFS , its own localization system, its own theme engine, performance monitoring, as well as constant refactoring (and sometimes rewriting the very core of the system at the next turn of the client’s understanding) and led by itself to the product, having looked at which any programmer would ask: “are you writing your CMS ?”. On what our complete misunderstanding would have received then, since we forgot to hang a label on what we are doing. With your permission, I will turn this story to a simple ending - everything turned out. I am not ashamed of my work, I had a great partner, with whom we regularly argued. The product is ready for use and it is only due to the client’s leisurelyness that our developers (of whom there are already 5 now, while the client has changed the management team and even the core of their IT department) there is still time to lick the product to unattainable perfection. Thus, despite our isolation from the world of .NET CMS , we have created our own. After my departure from the project, I decided to look at the options that we ignored. At our hearing in our office were Umbraco and Orchard. I decided to catch a glimpse of their code, knowing in advance that these products simply have to be good. So when I looked at their architectural solutions, I just wanted to know how else we could improve our own product. Actually, here I would like to know the opinion of people who continuously follow these CMS .

"Orchard" and "Umbraco 5"

Both CMSs use a kernel on which any modules can rely. By the way, JetBrains R # ^{5 is} used in both teams. This had a nice effect on the presentation of the code of both CMS . Also, both CMS use ORM NHibernate ⁶ and IoC Autofac ⁷ . I would like to focus attention first on these two facts for the sake of interest. Let's start with the last one.
')

IoC and extensibility in general

Umbraco tried to abstract from IoC by creating a set of shell interfaces. Thus, the developer is free to use any IoC container. However, when I tried to do this (Unity instead of Autofac, since in our project we had no other choice) I noticed a funny thing. In Umbraco, they simply copied the Autofac interface model. Those. when you actually implement the binding on Unity, this binding will look or feel like Autofac. In fairness it is worth noting that, despite the amusingness of this fact, to make the harness turned out. Well, how it happened - it compiles and passes the tests. Just for the sake of experiment tried. I see here one plausible explanation for this approach in Umbraco, although there are undoubtedly more of them. I don't know the truth. My explanation for myself is that the CMS was designed based on the IoC Autofac. And then the developers decided to abstract from a specific container, but without prejudice to the development, since the code was already written and the developers were already accustomed to the syntax. That is why it is so funny to switch to using another container. One could, of course, look at the change history of the CMS to be convinced or, on the contrary, to abandon my explanation as actually incorrect, but I didn’t have time for that. If there is anyone who follows the development of this CMS , I would like to hear about it in more detail. In any case, thanks to the developers for the existence of the possibility of replacing IoC . Sometimes developers do not want to use in their project several different libraries that solve one problem. Umbraco also uses MEF , which, to my surprise, could not be found in Orchard. The approach to creating modules in Umbraco, however, it seemed to me, is quite orthodox. Their team has written several templates with their type of project. It is worth noting that this amazing amount of work was done for a little gloss. Those. in the studio you see the brand icon on the Umbraco module project and, on the right mouse click on it or on any element, have a unique set of actions developed for this type of project or element. With their likely visual assistants and other things ... I repeat once again, this is a huge amount of work for the sake of a little gloss. However, it is worth noting, thanks to this, Umbraco is perfectly “felt” in the studio. Orchard’s modernist approach to this module is of little use in developing modules that use scaffolding ⁸ , which is so familiar to many people, and manifestos in plain text format, in this sense appeals to me more. As already mentioned, Orchard also, like Umbraco, uses Autofac as an IoC container. This fact alone has already caused me a question. It seems, Orchard originated in the depths of Microsoft, when preparing the next MIX ⁹ . At the same time, Orchard was conceived as an “ideologically pure” CMS , whatever that implied. What stopped developers from using Unity, which was born, like Orchard, at Microsoft? It also solves dependency control issues. In addition, the developers could not be unaware that the MEF for their system would be an excellent solution. Especially in light of the trends in MEF 2, which have made the apparent development a reality. Using technologies from Microsoft could improve them (Unity, classes in the namespace System.ComponentModel.Composition.Web.Mvc ...). Communication between different teams, but in one company after all, should still take place more intensively than between independent library developers and developers of another company. Not only that, Orchard uses Autofac at the core. Those. Connectivity with this container is much stronger than in Umbraco. Is it really so bad with Microsoft communications? I would very much like to hear at least some comments on this issue. From the point of view of using the system, this does not bother anyone, but it still does not give me a simple interest in peace.

NHibernate ORM and data layer

I will ask only one question here, since I was not very interested in this question. However. Why this ORM , but not EF ? Well, that is, I certainly understand that NHibernate has matured long ago, while EF is only approaching a normal data migration solution. But are there any plans for the transition? NHibernate in Orchard is as tightly integrated into the core as IoC . While at Umbraco, the orthogonality of the persistent mechanism was taken care of. In Umbraco, the use of Umbraco.Framework.Persistence.NHibernate is completely optional. As for the level of data in general, in both CMS it is at the highest level. Both have their own advantages. Umbraco boasts excellent orthogonality of the modules and the concept of hives (Hive), which are, in fact, abstract data providers. I heard a lot of negative reviews about previous versions of Umbraco (for obvious reasons, no one used the fifth version of this CMS , which wasn’t even in the beta stage) on live projects, when it came to caching and working with data in general. Something there was associated with XSLT , XML , otzhiraemy memory, poor performance ... I look at the fifth version of the CMS , not knowing anything about its previous versions. And I see that there are simply no problems that I had heard so much about from the staff in this version. Maybe, in previous versions, orthogonality was much worse, or the staff didn’t know something - I don’t know about it and I don’t even care about it now. Orchard, on the other hand, boasts its own content type system, which they claim is even more flexible than the CLR type system on which it is based, bearing in mind the dynamic type composition.

What is very nice hooked in "Orchard" and "Umbraco 5"

In Umbraco, a localization module ^{10 is} implemented, from which my brain burst. She is gorgeous! I could not imagine a more thoughtful and powerful localization system. I reassured myself that such a power would not be needed in our project. In fact, even that simple localization system that existed with us was already the pinnacle of customer expectations. But only because the client, like ourselves, did not have a special imagination. Therefore, I looked at the localization module in Umbraco 5, was pleased with the persistence and diligence of the people of this CMS and put the module apart for later. Until next life, maybe. Orchard did not eat my brain, but nevertheless, I really liked the elegance of their decisions. ¹¹ For example, the power of their engine, the ¹² , where you fully control the output of all that is possible. You also have the ability to override the standard output of widgets that you developed. The themes are interesting and simple, understandable to many of the concept of layouts and zones, which we also used in our CMS , however, the Orchard team made it much better and more qualitative, which, by the way, is understandable. I am also impressed by the principle of recipes ¹³ (high-level component configuration, where you specify which modules belong to your site), and streaming components, and a simple configuration system. Everything is done elegantly and there is a certain impression of ease of working with the system. It is also worth mentioning that you can set your own streaming components. This is very interesting for companies selling their system built on Orchard, with its components that are convenient only in the context of their domain. These components can be added to the recipe manually, or installed from the admin panel of the system. They also made it convenient to quickly change the views in the modules or the theme (due to dynamic compilation), due to which you don’t have to re-build the project.

What I personally understood

If you can, it is better to learn one some good CMS . At the moment there is plenty to choose from. All of them use orthogonality and try to maximize it. That is, you will win in any case (if it is not a trivial static page) and you can complete your project with fewer surprises and you can complete it much faster than without using CMS . I wonder what other insurmountable or very unpleasant surprises developers may have encountered while working with these systems (once again I want to remind you, I considered only Orchard v.1.3 and Umbraco v.5). The code is in front of the nose and it is much cleaner and more qualitative from an architectural point of view than most of what developers write without CMS . I chose Orchard for my next project, but only because of my personal preferences. Umbraco 5, after viewing the code of this CMS , was no worse than Orchard. And in some places the quality of performance is higher. However, I was bribed, as I have already said, by the seeming simplicity and the feeling of “lightness” when working with Orchard. As you can see, I still have some questions and it would be wildly interesting for me to know the answers to them, if any. Thank you, if you have read this towel to the end.

Source: https://habr.com/ru/post/138060/

All Articles