How do we switch from Telerik Open Access to anything else?

Question

Our company has been using Telerik Open Access for years. We have multiple projects using it including some in development and some in production that need updated. Because Telerik no longer updates or supports Open Access, we are having a variety of problems. We've got users that have to go to another work station because we can't get Open Access on their computers and we've got projects where we can't add or update tables because the visual designer doesn't work in modern Visual Studio versions. So my question is, how do we convert these and what do we convert these to?

I've heard of Microsoft Entities Framework and we used to just call stored procedures instead of having a separate data project. Obviously our clients aren't going to pay us for hours to switch so we need something that works quick. How do we convert our existing Telerik Open Access project to Microsoft Entities Framework, straight SQL queries, or some other data layer option?

Here's an example of what we have currently.

A separate Visual Studio project that acts as our data layer where all the code was created by Telerik Open Access's visual designer:

We then have a DataAccess.cs class in our main project that creates the instance of the data layer:

Then we call it by using linq statements in the main project:

Answer 1

I don't know OA hands-on, so I can only put my two-cents in.

I'm afraid this isn't going to be be an easy transition. I've yet to see the first seamless transition from one data layer implementation to another (and I've seen a few). The main cause for this is that IQueryable is a leaky abstraction. That is, the data layer exposes IQueryables, but

• it doesn't support all features of the interface, and
• it adds its own features, and
• it's got its own interpretation of how to implement the features that are supported.

This means that if you're going to port your data layer to EF, you may notice that some LINQ queries throw runtime errors because they contain unsupported .Net methods/properties (for instance DateTime.Date), or perform worse -- or better, or return data in subtly different shapes or sorting orders.

Some important OA features that are missing in EF:

• Runtime mappings (EF's mapping is static)
• Bulk update/delete functions (with EF: only by using third-party libraries)
• Second-leve cache
• Profiler and Tuning Advisor
• Streaming of large objects
• Mixing database-side and client-side evaluation of LINQ queries (EF6: only db-evaluation)

On the other hand, the basic architectures of OA and EF don't seem to be too different. They both -

• support POCOs
• work with simple navigation properties
• have a fluent mapping API
• support LINQ through IQueryable<T>, where T is an entity class.
• most importantly: both have revolve around the Unit of Work and Repository patterns. (For EF: DbContext and DbSet, respectively)

All-in-all it's goinig to be a delicate process of converting, trying and testing. One good thing is that your current DAL is already abstracted to a certain extent. Another is that the syntax doesn't even look too different. Where you have ...

dbContext.Add(newDockReport);
dbContext.SaveChanges();

... using EF this would become ...

dbContext.DockReports.Add(newDockReport);
dbContext.SaveChanges();

With EF-core it wouldn't even have to change one bit.

But that's another important choice to make: EF6 or EF-core? EF6 is stable, mature, feature-rich, but at the end of its life cycle (a phrase you've probably come to hate by now). EF-core, on the other hand, is the future, but is presently struggling to get bug-free in its major functions, not yet as feature-rich as EF6 (and some features will never return, although other new features are great improvements compared to EF6). At the moment, I'd be wary of using EF-core for enterprise applications, but I'm pretty sure that a year from now this is not an issue any more.

Whichever way you go, I'd start the process by writing large amounts of integration tests, if you didn't do so already. The advantage of integration tests is that you can avoid the hassle of mocking either framework first (which isn't trivial).

Answer 2

I have never heard of a tool that can do that.Expect it to take time.

You have to figure how to do it by yourself : ( for the exact safer way to migrate )

1rst you must have a simple page that use your DataLayer it will be your test page. A simple one that you can adapt the LinQ logic .

1. Add a LinQ to SQL Class, Right click> Add > LinQ to SQL Class.
2. Drop your table for this page only the usefull one, put the link if needed.
3. In the test page create a new data context of the linQtoSql.
4. Use it fixing the type and rename what have to be rename.
5. Fix error till it compile.

Stock coffee and anything that can boost your brain.

1. Add table to your context to match the one you had in telerik data access.
2. Debug for days.
3. Come back with new question on how to fix a new issue twice a day.

Answer 3

To help with the dbContext.Add() difference between the 2 frameworks you could use this extension in the EF 6.x :

public static void Add<T>(this DbContext db, T entityToCreate) where T : class
{
    db.Set<T>().Add(entityToCreate);
    db.SaveChanges();
}

then you could do :

db.Add(obj);

See Gert Arnold answer : In Entity Framework, how do I add a generic entity to its corresponding DbSet without a switch statement that enumerates all the possible DbSets?