CMS, CMF, ERP do it yourself
I myself am a rather lazy programmer. Perhaps that is why I was pursued for a long time by the idea of creating a tool suitable for solving a wide range of tasks of a small enterprise. This is how the architectural template of the corporate information system appeared, which I first applied in the development of the company's web-platform in the form of OpenKit.net CMS / CMF.
The invention of bicycles is not my favorite activity. In addition, I am aware of the fact that most of the new software technologies are based on the ideas of half a century ago. Therefore, when I first thought about the realization of my dream, I went to the bookstore, hoping to get one of the classics.
')
The first was Bertrand Meier’s book Object-Oriented Design of Software Systems (a weighty brick of 1000 pages, but on the other hand, who is easy now?). As I read, the feeling that this is exactly what I needed increased. Imagine: you can start writing an application for accounting, gradually add more and more new features, and then, after a while, look back, and - bang - and the program is already there to control the orbital station!
Of course, there is a share of joke in this joke, but basically it’s true: a real system should not have a main function. “What does this system do?” Is the last question the designer must ask. If you only learned about it for the first time now, then most likely you have nothing to do with object-oriented programming, even if you really like the words “class” and “object”. This is how it is. I did not know until I read about it.
I was particularly interested in the idea of building systems from clusters, which I tried to translate into the project to the best of my understanding and capabilities. As a result, thanks to the universality of .NET, an even more universal system turned out than I originally intended. For example, it turned out that it is possible to build a whole city of different types (web, winForms, Console, Remoting services, etc.) from “notovsky” clusters, nevertheless built according to one architectural pattern.
In general, this is another version of the old abstract and widespread scheme “core (engine, shell) + modules”. Unfortunately, its implementations often suffer from one serious disease: modules, one way or another, are integrated with the kernel. Because of this, the number of interconnections within the system grows exponentially with the addition of new functions. To make changes every time it becomes harder and harder for developers, the cost of maintenance grows as rapidly and inevitably there comes a time when developers lose control of the cumbersome and already super expensive system.
There is only one cure for this: autonomous modules on the one hand, and complete independence of the shell from the contents of the modules on the other. Having accepted the “module = cluster”, I present a version of a tool suitable for solving a wide range of applied corporate tasks and not suffering from the aforementioned disease.
The solution consists of two parts:
1. The API of the stand-alone module, common to all the different types (web, winForms, Console, Remoting Services, etc.) modules developed by the company ...
2. One graphical shell for each type of application (for the Web - its own, for winForms - its own, etc.), which provides access to these components and organizes work with them through this API.
A schematic diagram of the solution is shown in the figure below:
The proposed architecture of the corporate information system and its module.
1. Architectural template module
Graphically, the structure of the module can be represented as follows:
Cluster Implements an open (public) abstract class that the shell (for example, CMF) searches in a module (in a dll assembly) via .Net Reflection. It is from this class that CMF “learns” about what kind of functionality is enclosed in a module, whether it has a web-facade, on the basis of which it becomes clear whether it can be registered in a web-shell.
The task of the cluster is to unite the applied object models related by meaning. This is an administrative unit for managing software functionality.
Web facade - This is a class with an open interface, through which CMF will know which web adapters are contained in this module and through which it works with them.
A web adapter is a class that provides a graphical web interface for working with some part of an applied object model. For example, displays a list of articles. For those familiar with ASP.NET, you can think of it as an ascx control, only located not in a separate ascx file, but in an assembly.
Similarly, there may be a facade and adapters for winForms. The adapter in this case will be the form class, which can be transferred from the server to the graphical shell to the client by Remoting and then run. The idea of implementing this can be found on the RSDN website in a seven-year-old article “Using Remoting in multitier applications”
Please note that changes in the data structure and the associated changes in the graphical interfaces do not require intervention in the code of different programs, but are made within the entire assembly.
A more detailed description of the module can be found in the developer’s guide on the project site , which also contains its source code.
2. Graphic shell.
The main task of the shell is to give the user access to the functionality of the modules. In a shell like a mosaic, the graphical interfaces they provide are assembled. For example, a web-shell (CMF) organizes work with HTML interfaces, winForms shell - with forms, etc ... Adding / removing modules from the shell is done exclusively by software, without manual configuration in a heap of files. In theory, this should be a relatively simple part of the architecture, which, in principle, should not be affected by any changes in applied object models ...
This architecture solves three issues at once: corporate interface, single authentication and deployment. Accordingly, all these issues are removed from the application modules (applications), thereby significantly simplifying them.
With regard to deployment, in the case of winForms on client machines, it suffices to put only a shell, and the entire application filling, including GUI modules, will be located on the server. Thus, even the deployment and maintenance of winForms applications will not differ from web applications, requiring changes in only one place (on the server), which simplifies (cheapens) system administration.
The most interesting thing is that the fundamental difference between the site, the desktop application and the complex solution of the enterprise is erased , since all of them are based on the same modules. That is why it is possible, for example, to start with a business card site and gradually turn it into a platform for the entire enterprise, expanding the configuration, but without changing the system architecture!
However, during the implementation, I stumbled upon a large pitfall. Although this architecture is possible only because of the universality of .NET, in spite of all the efforts, I was not able to fit ASP.NET into it. The catch is that, on the one hand, ascx controls and dll assemblies cannot be “torn off” from aspx pages - there is a fatal rigid connection between them, on the other hand, aspx pages cannot be arbitrarily launched like winForms, without being tied to the file system. Attempt to pull the concept of winForms on the web (the basic idea of ASP.NET) to the end was somehow not brought.
The consequence of this, when designing CMF OpenKit.net , was the forced rejection of what is considered ASP.NET technology. This entailed both positive and negative points. The downside is that the developer of the CMF modules can use the controls built into the Framework only programmatically. The advantage is that the developer can now be completely forgotten about ASP.NET, while retaining the ability to compile code.
In general, the idea to pull the concept of winForms on the web personally seems to me rather doubtful. In winForms applications, it is impossible to do without a component GUI in principle. But on the web, with its HTML, CSS, JavaScript ...? Excuse me. Simplification of insignificant aspects, such as, for example, stitching interface primitives into server controls, etc., cost a huge complication of the technology as a whole. However, as it turned out, without knowledge of ASP.NET it is quite possible to do when developing web applications on .Net. Neither the developers of the modules, nor the OpenKit administrators, knowledge of ASP.NET is required at all, which, IMHO, has greatly simplified life.
As a result, we have: instead of a heap of disparate applications written in an unknown way as well as in an unknown way - dozens of modules, perhaps even of different types, but with the same architecture, written in one language (not counting JavaScript), according to one standard and combined in one or two graphical shells. The cost of maintenance tends to be minimal, the corporate information system as a whole is simplified and, therefore, it becomes more reliable and cheaper to maintain.
For a small company, this solution can be a low-cost alternative to ERP and similar systems. Its developers can create on their own only the functionality that is really in demand at the enterprise, not overpaying for the excess functionality and lack of flexibility of the purchase solutions on the one hand and avoiding “patchwork automation” from the heap of disparate programs on the other.
PS Laziness: a quality that forces you to put more effort into reducing overall energy costs. It makes writing programs that facilitate work, and document writing, so that you do not have to answer unnecessary questions. (Larry Wall, I quote from Steve McConelle "Perfect Code", M. 2005, p. 810)
The invention of bicycles is not my favorite activity. In addition, I am aware of the fact that most of the new software technologies are based on the ideas of half a century ago. Therefore, when I first thought about the realization of my dream, I went to the bookstore, hoping to get one of the classics.
')
The first was Bertrand Meier’s book Object-Oriented Design of Software Systems (a weighty brick of 1000 pages, but on the other hand, who is easy now?). As I read, the feeling that this is exactly what I needed increased. Imagine: you can start writing an application for accounting, gradually add more and more new features, and then, after a while, look back, and - bang - and the program is already there to control the orbital station!
Of course, there is a share of joke in this joke, but basically it’s true: a real system should not have a main function. “What does this system do?” Is the last question the designer must ask. If you only learned about it for the first time now, then most likely you have nothing to do with object-oriented programming, even if you really like the words “class” and “object”. This is how it is. I did not know until I read about it.
I was particularly interested in the idea of building systems from clusters, which I tried to translate into the project to the best of my understanding and capabilities. As a result, thanks to the universality of .NET, an even more universal system turned out than I originally intended. For example, it turned out that it is possible to build a whole city of different types (web, winForms, Console, Remoting services, etc.) from “notovsky” clusters, nevertheless built according to one architectural pattern.
In general, this is another version of the old abstract and widespread scheme “core (engine, shell) + modules”. Unfortunately, its implementations often suffer from one serious disease: modules, one way or another, are integrated with the kernel. Because of this, the number of interconnections within the system grows exponentially with the addition of new functions. To make changes every time it becomes harder and harder for developers, the cost of maintenance grows as rapidly and inevitably there comes a time when developers lose control of the cumbersome and already super expensive system.
There is only one cure for this: autonomous modules on the one hand, and complete independence of the shell from the contents of the modules on the other. Having accepted the “module = cluster”, I present a version of a tool suitable for solving a wide range of applied corporate tasks and not suffering from the aforementioned disease.
The solution consists of two parts:
1. The API of the stand-alone module, common to all the different types (web, winForms, Console, Remoting Services, etc.) modules developed by the company ...
2. One graphical shell for each type of application (for the Web - its own, for winForms - its own, etc.), which provides access to these components and organizes work with them through this API.
A schematic diagram of the solution is shown in the figure below:
The proposed architecture of the corporate information system and its module.
1. Architectural template module
Graphically, the structure of the module can be represented as follows:
Cluster Implements an open (public) abstract class that the shell (for example, CMF) searches in a module (in a dll assembly) via .Net Reflection. It is from this class that CMF “learns” about what kind of functionality is enclosed in a module, whether it has a web-facade, on the basis of which it becomes clear whether it can be registered in a web-shell.
The task of the cluster is to unite the applied object models related by meaning. This is an administrative unit for managing software functionality.
Web facade - This is a class with an open interface, through which CMF will know which web adapters are contained in this module and through which it works with them.
A web adapter is a class that provides a graphical web interface for working with some part of an applied object model. For example, displays a list of articles. For those familiar with ASP.NET, you can think of it as an ascx control, only located not in a separate ascx file, but in an assembly.
Similarly, there may be a facade and adapters for winForms. The adapter in this case will be the form class, which can be transferred from the server to the graphical shell to the client by Remoting and then run. The idea of implementing this can be found on the RSDN website in a seven-year-old article “Using Remoting in multitier applications”
Please note that changes in the data structure and the associated changes in the graphical interfaces do not require intervention in the code of different programs, but are made within the entire assembly.
A more detailed description of the module can be found in the developer’s guide on the project site , which also contains its source code.
2. Graphic shell.
The main task of the shell is to give the user access to the functionality of the modules. In a shell like a mosaic, the graphical interfaces they provide are assembled. For example, a web-shell (CMF) organizes work with HTML interfaces, winForms shell - with forms, etc ... Adding / removing modules from the shell is done exclusively by software, without manual configuration in a heap of files. In theory, this should be a relatively simple part of the architecture, which, in principle, should not be affected by any changes in applied object models ...
This architecture solves three issues at once: corporate interface, single authentication and deployment. Accordingly, all these issues are removed from the application modules (applications), thereby significantly simplifying them.
With regard to deployment, in the case of winForms on client machines, it suffices to put only a shell, and the entire application filling, including GUI modules, will be located on the server. Thus, even the deployment and maintenance of winForms applications will not differ from web applications, requiring changes in only one place (on the server), which simplifies (cheapens) system administration.
The most interesting thing is that the fundamental difference between the site, the desktop application and the complex solution of the enterprise is erased , since all of them are based on the same modules. That is why it is possible, for example, to start with a business card site and gradually turn it into a platform for the entire enterprise, expanding the configuration, but without changing the system architecture!
However, during the implementation, I stumbled upon a large pitfall. Although this architecture is possible only because of the universality of .NET, in spite of all the efforts, I was not able to fit ASP.NET into it. The catch is that, on the one hand, ascx controls and dll assemblies cannot be “torn off” from aspx pages - there is a fatal rigid connection between them, on the other hand, aspx pages cannot be arbitrarily launched like winForms, without being tied to the file system. Attempt to pull the concept of winForms on the web (the basic idea of ASP.NET) to the end was somehow not brought.
The consequence of this, when designing CMF OpenKit.net , was the forced rejection of what is considered ASP.NET technology. This entailed both positive and negative points. The downside is that the developer of the CMF modules can use the controls built into the Framework only programmatically. The advantage is that the developer can now be completely forgotten about ASP.NET, while retaining the ability to compile code.
In general, the idea to pull the concept of winForms on the web personally seems to me rather doubtful. In winForms applications, it is impossible to do without a component GUI in principle. But on the web, with its HTML, CSS, JavaScript ...? Excuse me. Simplification of insignificant aspects, such as, for example, stitching interface primitives into server controls, etc., cost a huge complication of the technology as a whole. However, as it turned out, without knowledge of ASP.NET it is quite possible to do when developing web applications on .Net. Neither the developers of the modules, nor the OpenKit administrators, knowledge of ASP.NET is required at all, which, IMHO, has greatly simplified life.
As a result, we have: instead of a heap of disparate applications written in an unknown way as well as in an unknown way - dozens of modules, perhaps even of different types, but with the same architecture, written in one language (not counting JavaScript), according to one standard and combined in one or two graphical shells. The cost of maintenance tends to be minimal, the corporate information system as a whole is simplified and, therefore, it becomes more reliable and cheaper to maintain.
For a small company, this solution can be a low-cost alternative to ERP and similar systems. Its developers can create on their own only the functionality that is really in demand at the enterprise, not overpaying for the excess functionality and lack of flexibility of the purchase solutions on the one hand and avoiding “patchwork automation” from the heap of disparate programs on the other.
PS Laziness: a quality that forces you to put more effort into reducing overall energy costs. It makes writing programs that facilitate work, and document writing, so that you do not have to answer unnecessary questions. (Larry Wall, I quote from Steve McConelle "Perfect Code", M. 2005, p. 810)
Source: https://habr.com/ru/post/64140/
All Articles