Skip to main content

Why Xomega?

Let's take a look at some unique Xomega features that set it apart from other code generators and low-code platforms.

Go beyond just table editors​

A lot of code generators work primarily off of the structure of your database and, therefore, can generate little more than just a UI for browsing and editing your database tables. This is rarely the way you need your application to look for all but the simplest views.

By contrast, Xomega generates the UI based on the structure of your service operations, which can range from straight reads and updates for a single table to sophisticated nested data structures that may involve any fields from other tables, calculated fields, or even fields from external sources.

If you think about it, you'll see that the structure of the service operations maps much better to the structure of your UI. Indeed, for any field that you need to display on the screen, you usually need it present in the corresponding read or read list operation to populate that field. Similarly, editable fields on the screen must usually be present in the create or update operations so that you can pass their values to the service for any updates.

As a result, the UI generated by Xomega will be much closer to what your app needs and will require minimal customizations to the point where it could be easily regenerated later when you need to update your service model.

XML modeling done right​

Many graphical modeling tools use an XML format to store their models. Still, that XML is generated entirely by the visual designer, stored as one big file, and is not intended to be read, let alone edited, directly by humans. If you've been using .NET long enough, you may remember the now obsolete Entity Data Model designer that is just like that.

With such tools, you were pretty much limited to what is supported by the model designer. If you need to search for some elements, for example, the designer would have to support that. You cannot add your own custom elements, and any refactoring must be done through the designer.

Moreover, if multiple developers collaborate on the same model, then you will need to merge the auto-generated XML from other commits and resolve any conflicts, which can result in invalid model XML that you may have no way of fixing using the designer alone. So you would still end up having to manually edit this auto-generated, not user-friendly XML, which can be a miserable experience.

Don't get us wrong, a graphical designer for a model could be great. But most developers have no problems, or even prefer, editing the markup directly, whether switching to XAML or ASPX view from the WYSIWYG designer or editing HTML in the razor files. Even Microsoft seems to be putting more focus now on editing the markup coupled with Hot Reload than on providing a UI designer.

Xomega models​

Enter Xomega modeling, where the model for each logical unit, such as related to a specific domain object, can be stored in separate files in a user-friendly XML format, just like the regular source code for C# classes that we all know and love.

You can search for any text or even replace text using standard Visual Studio tools. You can define and provide any additional custom configuration to Xomega model elements without needing designer support for those. And you can merge any changes and resolve conflicts just like you do with the regular source code. The change history log also becomes more meaningful and useful, as it contains manual changes rather than changes for auto-generated XML.

But wait, it gets even better! You may know that manually editing raw XML documents with the standard Visual Studio editor is no fun. So Xomega.Net provides a custom XML editor for Xomega models, which supports better outlining, collapsing to definitions, built-in validation of model entities, IntelliSense, and other features that make model browsing and editing quite enjoyable.

What also makes Xomega models user-friendly is their minimalistic structure, where you can provide just the minimal data elements needed, while Xomega will derive the rest from other elements and their relationships.

Write portable and testable code​

When building applications using traditional development frameworks, rarely can developers write application code that is fully independent of the target platform or framework. So, the presentation logic for the application would be inseparable from the selected UI framework, such as WPF or Blazor, and the service logic may be tightly coupled with the communication framework, such as WCF or WebAPI, even though nothing in this logic may require dependencies on those frameworks.

This locks you into the selected technology stack and frameworks and makes it quite challenging and costly to upgrade your app to newer technology in the future. Considering the ever-increasing pace of technological change, your app can be at risk of quickly becoming not maintainable as the frameworks it depends on get abandoned or fall out of support. Oftentimes, even when you start a big project with a brand new framework, that framework will be already obsolete by the time you finish the project.

And if you have been in technology long enough, you'd know that it can happen regardless of whether that technology or framework is provided by a large company like Microsoft (remember Silverlight or LightSwitch?) or by a small vendor. The only real way to keep up with this constant change is to keep investing in the upgrades. And to minimize those investments, you want to ensure that your application code is as portable as possible.

Xomega Framework​

Our open-source Xomega Framework has been designed to allow you to write the bulk of your presentation and service logic in a platform-agnostic way, which you can then hook into a thin platform-specific layer.

On the presentation layer, the same common logic can be shared not just between web clients, such as Blazor Server, WebAssembly, or even legacy ASP.NET WebForms, but also between other types of clients, such as WPF desktop applications or even with the multi-platform MAUI applications, when those become supported.

On the service layer side, the same services that you build can be either invoked directly, e.g., from Blazor Server apps, or exposed via REST API, e.g., for WebAssembly apps, or even through the legacy WCF framework. This also allows you to easily add another communication layer, such as gRPC, with little to no changes to your services.

An added benefit to writing platform-independent logic is that it will make your code much more testable since you can just run it within the testing framework without dealing with all those platform-specific layers.

And let's not forget about the learning curve. When you can write your apps the same way for any platform, you will not need to re-learn a new framework each time, which would be a huge boost to developer productivity.

Customizable and extensible​

There are many great benefits in having standardized screens with a consistent look and feel across your app - from code generation and ease of maintenance to a reduced learning curve for both developers and the users of your application.

At the same time, we all know that every application may have its unique functional requirements and may need its own distinguished look and feel to meet specific user needs and avoid looking like a cookie-cutter app.

Also, while Xomega tries to assemble the best technology stacks and use the best development practices for building your apps, we realize that every organization may have its own set of technology standards and requirements.

Therefore, the Xomega platform was designed with customization, extensibility, and openness in mind.

Xomega provides plenty of ways to customize the generated code - from updating the model accordingly to writing custom code and even modifying the source code of the generators to output everything the way you need. It also tries to do it in such a way that you could regenerate all artifacts at any point without losing your customizations and thus get the best of both worlds.

With Xomega Framework being open-source, it allows you to easily troubleshoot any issues and suggest bug fixes or even new features in order to help both your project and the community at large. The framework is also designed to allow you to substitute standard components with your own, override standard behavior in your custom classes, and otherwise customize your app to your own needs.

For the most advanced cases, you can even extend the Xomega model with your custom elements and attributes and leverage Xomega.Net to provide validation, IntelliSense, and collapsing for such elements. Then you can modify the generators to use the new custom elements to generate your artifacts.

Alternatively, you can create your custom generators that could use both the standard and your custom model elements to generate new types of artifacts from the model, such as automated unit tests. Because both the models and the generators are built using standard tried-and-true XML technologies, it will be easy for you to find the necessary resources for this.