Support for .Net Core added to Xomega for VS 2017

We are excited to announce a new Xomega release 7.9 for Visual Studio 2017.

The main target of this release is the support of .Net Core, which allows you to use the latest, yet already quite mature Microsoft technologies, in order to quickly build high-performance cloud-enabled web applications in addition to the regular desktop apps.

Here is a summary of the new features in this release.

Support for Entity Framework Core.

You can now generate the entities and DB context classes either for the original EF 6.x or for the new EF Core, based on a flag set in the global entities configuration in the model. You can also generate extended partial classes for selected entities to add your custom code to.

ASP.NET Core REST Services.

The project for REST services has been updated to use ASP.NET Core 2.2 and EF Core instead of the older OWIN-based Web API package. This allows you to easily host your REST services on any machine as well as on the cloud.

To improve performance of the REST services, they now use asynchronous services by default, which helps them handle higher volumes of requests. You can still use traditional synchronous services though by setting the corresponding async parameter on the global services configuration in the model.

Updated Project Templates.

Project templates for creating new Xomega solutions or individual projects have been updated to use EF Core, but the legacy templates for EF 6.x are also available as an alternative.

All shared projects use the slim .Net Core format now, which makes them automatically pick up new changes after code generation without having to reload them.

Right after you add a new solution, you will be able to build it now without having to build the model project first.

And finally, all third party NuGet packages for the solution will be installed from the standard sources configured in your Visual Studio, such as nuget.org, instead of the local file system. This helped to cut the size of the installation download almost in half by not including any external packages.

For Visual Studio 2015 users

Unfortunately, Visual Studio 2015 does not support the latest .Net Core projects, nor is it likely to support them in the future, given the upcoming release of the VS 2019. Therefore, these new features will be only available for VS 2017 and up.

We did release a patch 6.8.1 for VS 2015 though, which contains some fixes for the previous release. Note that after we release a Xomega version for VS 2019, support for the VS 2015 version will be discontinued, so we recommend that you upgrade to the latest version of Visual Studio.

We hope that you’ll enjoy the new features once you go ahead and install the new release, but please feel free to contact us if you have any questions or issues.

Read More

Introducing support for Flexible Operators

In release 7.8 Xomega has tremendously improved support for operators that are used to build search forms and LINQ queries.

Thanks to the framework support, using operators to build LINQ queries takes just a single line of code now. The framework comes loaded with standard operators for common data types, as well as dynamic operators for ranges of (relative) dates and numbers. Plus, it allows you to implement and plug in your own operators or override the behavior of any of the built-in operators.

Read on to learn more about these powerful features.

Framework to support operators for building queries.

While Xomega supported operators for query operations before, it was using a predefined list of operators, and each operator was handled explicitly for each criteria in the generated service, which resulted in a rather bloated and inflexible generated class.

With addition of the operators support to the Xomega Framework, including in the BaseService class, handling any criteria with operators takes just one line in the service now. Not only does it make the generated code much more cleaner, but it also helps writing custom code for non-standard criteria so much easier.

Standard operators for common data types.

Xomega Framework provides implementation for most of the standard operators on the common data types, such as Is Null, Equals To, Less Than and Greater Than, Between etc., including the corresponding inverse operators.

You can also develop and register your own implementation of any custom operator, or even override implementation of any of the standards operators.

Dynamic operators for date ranges using relative dates.

In addition to the standard predefined operators, Xomega Framework supports dynamic operators for date ranges. For each upper/lower bound of the range you can use either an absolute date or a relative date, such as ‘ct’ for the current time, ‘bo(s/m/h/d/w/M/y)’ for the beginning of second, minute, hour, day, week, month or year respectively, or the ‘eo(s/m/h/d/w/M/y)’ for the end of the same period.

You can further adjust it by adding or subtracting a certain number of periods, e.g. -60d to subtract 60 days, and also indicate whether you want to include or exclude the bound by using either square brackets or parentheses respectively.

For example, Xomega supplies the following standard dynamic range operators for relative  dates, but you are free to define your own operators like that in your Xomega model.
      <item name="Today" value="[bod,eod)"/>
      <item name="This Week" value="[bow,eow)"/>
      <item name="This Month" value="[boM,eoM)"/>
      <item name="This Year" value="[boy,eoy)"/>
      <item name="Last 30 Days" value="[bod-30d,ct]"/>

Dynamic operators for number ranges.

Similar to the date ranges, Xomega Framework also supports dynamic operators for numeric ranges. So, for certain numeric fields you may want to let the user select criteria for some  predefined ranges instead of, or in addition to, manually supplying the From and To values.

For example, to filter something by price you can define low, medium, and high price ranges,  which you can call  Budget, Average and Luxury respectively, as follows.
      <item name="Budget" value="[0,100)"/>
      <item name="Average" value="[100,1000)"/>
      <item name="Luxury" value="[1000,)"/>

These operators do not require additional values, and are more convenient for the user. If none of your operators for a certain field require additional values, then you can also make the operator parameter multi-value in the Xomega model, which will allow the user to filter by multiple ranges at the same time.

Read More

New Service Validations in Xomega 7.8

Xomega now supports more easy and powerful validation on the server side, which ties into the Xomega error reporting framework.

This includes service request validations using Data Annotations, as well as user-friendly errors for common constraint violations as follows.

Improved validation of entity existence.

The services project template includes a convenient extension method to find entities by the key(s) and report an immediate 404 error if the entity is not found. This method is used by the generated services, and can be used by the custom code, which makes the code much cleaner.

Improved validation of foreign keys.

Similar to the entity existence validation, there is now a simple method to validate if the supplied foreign key(s) are valid. Unlike the previous validation though, it reports a regular error, which allows to gather all applicable errors before running the business logic and report them in a user-friendly fashion, as opposed to the DB constraint violation errors.

Validation of duplicate primary keys.

Another added validation that is also used by the generated services allows you to validate if the entity with the given key(s) already exists when creating a new domain object, which also reports a user-friendly error instead of a DB primary key violation.

Request validation of required fields, maximum length and enumerations.

The UI forms generated by Xomega already take care of validating user input in terms of required fields, maximum length etc. and make sure the values for enumerated fields are selected from the associated list.

However, the best practices for multi-tier architectures call for the business services that are exposed via REST or WCF to also perform such validations, without relying solely on the client for those. While some of these checks would be done by the database as well, Xomega now validates request values upfront, and reports user-friendly errors before running the business logic.

Read More

Improved Error Reporting in Xomega 7.8

Xomega has made some significant changes in the way errors and other messages are reported from the business services and displayed to the user.

This includes ability to return not only errors, but also warnings and info messages from any service operation in a standardized way, and handle them consistently by displaying them in a configurable closable panel as described below.

Ability to return (warning/info) messages from services along with the results.

Validation errors, as well as other types of errors from business services are returned to the client using standard Xomega Framework structures for error messages, which allows handling them consistently on the client side. However, if a service operation succeeds and has no errors, but still needs to report some warning or info messages to the client, potentially also with the actual results of the operation, there was no standardized way to report those, and you’d have to custom design each such operation to return the necessary messages.

With the new release, each Xomega service operation now returns a standardized list of errors, warnings and/or info messages in addition to the actual results of the operation, where applicable. This way any service operation can easily report additional warning or info messages, which would be displayed to the user, without having to customize its output structure.

For example, an update service operation may report some warnings to the user based on business validations. Or a service may report cross-cutting messages informing the users about a scheduled downtime or about a newer version of the service available.

Reported messages and errors displayed consistently in a closable panel.

Previously the validation and service errors were displayed inconsistently across the UI clients as a simple list either on the screen or in a popup dialog for WPF clients. The errors could be closed also inconsistently - by closing the dialog in WPF, after any postback in WebForms, and after re-running the validations and the service operation in the SPA client.

In the current release, all Xomega messages from client-side validation or service operations are consistently displayed in a closable panel on the same view that triggered the operation as shown below.

This way the users can have the messages up while they are addressing the errors on the screen, or they can just close it if they don’t need it anymore.

Configuration of the messages panel layout.

In addition to the messages being in a closable panel now, you can now configure whether you want to display it at the top or the bottom of the form for both the search and details screen. This is done as part of the view layout configuration in the model, which you can configure in one place, or override for each individual view as needed.

Read More

Globalization Support in Xomega 7.8

Xomega release 7.8 has added support for globalization of the business services to allow translating messages to the language of the request and overriding framework’s default messages, and uses the current request culture for date operations as follows.

Error messages read from resources for globalization.

The text for error messages from the Xomega Framework as well as server-side validations is now read from the resource files, allowing to provide such texts in multiple languages, and return localized error messages in the language of the service request.

Ability to override and translate text for message from referenced libraries.

The default implementation of the ResourceManager in the .Net framework allows reading the text only from a specific resource or its satellite localizations. As a result, when such resources come from a third party library, such as the Xomega Framework itself, the application has no way of customizing the text of the messages used by that library.

With addition of the CompositeResourceManager in the Xomega Framework, you will be able to not only translate the framework’s messages into another language, but also override the default (English) text for some of those messages.

Use of request culture for date operations.

In addition to translation of the error messages, the services can use the current request's culture for date operations. For example, when filtering dates for the current week, Xomega Framework will use the current culture to determine the first day of the week, i.e. Sunday or Monday.

Read More

Entities generation revamped in Xomega 7.8

Starting from release 7.8, Xomega has completely upgraded the way Entity Framework classes are generated.

Entity Framework classes are generated now directly from the Xomega model.

Previously, the Entity Framework (EF) classes were generated using standard Model-First EF T4 templates from an Entity Data Model (EDM), which was in turn generated from the Xomega model. Now they are generated directly from the Xomega model using a new Xomega generator called EF Domain Objects. Generating EDM is no longer needed for the application, but that generator is still available in case you want to view your entity model on graphical diagrams.

This provides a lot of benefits as a result, such as the following.

• Full control over the way Entity Framework classes are generated.
• Ability to output generated classes using Xomega standards - grouped in sub-folders by module, individual files in a single folder, or even all generated classes in a single file.
• Generated classes and their fields now have documentation comments from their Xomega model’s doc elements to help developers use them correctly.
• No need to run T4 templates after the Xomega generation, which was failing sporadically, resulting in compile and run-time errors after domain model updates.
• No need to maintain edm:type configurations on logical types, unless you need to generate an EDM for diagrams, since Xomega uses now the clr:type configurations instead.
• Ability to use Entity Framework Core in the future, which does not support EDM.

Entity configurations are generated by each entity using Fluent API.

Without the generated EDM, the EF classes use Fluent API now to configure the domain entities. Unlike the standard EF generators that create entities from database tables and output all configurations into a single method OnModelCreating of the generated DbContext class, configurations for entities generated from the Xomega domain objects are segregated neatly into separate files for each entity, which makes them much more easier to work with, and keeps the code for the entities and the context very clean.

Fluent API allows you to easily customize or override configurations of each entity without touching the generated code. For example, you can tweak configurations of any property,   entity or relationship in a subclass of the generated DB context, and then register that subclass with the Dependency Injection container.

Read More