Possiblity of Migration

[G W]

Hello, I am looking into solutions to replace the existing ORM in a fairly large project.
So far to me I'm leaning toward using LLBLGen to handle it, but since my company owns and uses Telerik products they would like to use OpenAccess instead of buying another tool.
One major benefit of OpenAccess that I keep reading about is how great your support is, so i got the idea to try to explain my concerns to you and see what insight you can offer.

So I'm wondering if you could help persuade me that your solution will work as well as LLBLGen, or help me find the limitations it might have in my specific case.

Here are 5 questions regarding each of the 5 situation that are detailed below these:
1. Will I be able to use reverse mapping to be able to use our current database, then start using forward mapping so that OpenAccess can generate the alter scripts instead of me doing that?  (Our project often adds new columns or new objects)
2. To convert it from DataAdaptors will I be able to use Regex replaces in the code, or will each load/save take manual changes to all the properties?
3. Linq-to-SQL would start using tons of RAM if i selected all the rows and columns and basically freeze, so I only select the IDs and use Take(), not the rest of the properties.  What kind of overhead would OpenAccess have compared to Linq-to-SQL, or the frameworks LLBLGen supports?
4. Any concern with different applications using different copies of the OpenAccess built pieces at the same time?  What would happen if i update a database to have newer columns but keep trying to use older code that does not have that column?  (Would it cause any exceptions when only adding new columns, would it cause that data to be deleted if the row was saved with the older version?)
5. I guess this goes back to the overhead concerns in question 3.

In my ASP.Net product we have the following situation that i'm wondering how much of it will need to be rewritten to work with either OpenAccess or the frameworks LLBLGen can generate:
1. The previous ORM put all the properties for the same "business object" into the same table, so we've ended up with the main table having 230 columns, most of which are always null.
2. It used DataAdaptors and DataSets, so it uses that style of calls to load/save data
3. To get the speed we needed when filtering from a selection of say 1000 rows (which in the DataSet would have 230 columns each) I built a Linq-to-SQL interface that gets the IDs that i load into the DataSet
4. We have 2 or 3 seperate apps which access the same database (they write to different sections so locking isn't a huge concern) with in general 5 users on both of those at a time
5. We need to export data fairly often, so exporting 1000 rows with data that might be generated using any number of those 230 columns


Other concerns:
I've used your product in a small project in an early version, it seemed like the design interface was somewhat slow to work with, and we never bothered upgrading the version (I can't remember if we tried but it was difficult to do or the project just completed)
1. How well do you claim that the design interface will work with a table with 230 columns, and others with 150 columns at the same time?
2. When i used it I thought I had the ability to store multiple business objects in the same row, so each different object would have the ability to select different columns.  Do you have that ability or was i mistaken?
2. How seamless is upgrading from one version of OpenAccess to a newer one?  The RadControls seem to change significantly on all major versions, so I neglect to upgrade those much of the time.

Thank you for any insight you can give me, I need to decide if I want to fight for my previous opinions or change them and agree to using OpenAccess.

[Ivailo]

Hello G W,

In general, if you are already using Telerik products, there is a huge benefit for using the Telerik OpenAccess ORM due to its integration with them.

In details, here are the answers of your questions and concerns:

1.1 Yes. We call this approach the “round-trip mapping” and it is one of the main capabilities of our Visual Designer. You can take a look at the videos for Database First and Model First approaches to see how you could achieve those two steps, having in mind that you can use them in any order, repeatedly.

1.2. Could you elaborate a bit on this question, I am not sure I fully understood it– are you asking about the code generation based on the model, the definition of data connections (like connection strings for instance) or something else?

1.3.    OpenAccess ORM uses lazy loading for data retrieval, in fact that is the default behavior of the products runtime. If you need to select a tree of objects, you can specify using a Fetch Plans API what exactly would you like to retrieve. OpenAccess ORM supports LINQ queries for your data manipulations.

1.4.    Discrepancies between the model and the database are allowed. In other words, if you add a column, you will still be able to use the table, unless the columns is not nullable, in which case the inserts will of course fail. However, we don’t recommend you to use this capability too much because of the higher probability of data integrity exceptions due to new constraints.

2.1 There are different options for you in OpenAccess ORM. Using the inheritance, which is easily defined by the Visual Designer, you can either store each class of a hierarchy in its own table (vertical and horizontal inheritance) or you can persist all of them into one table (flat inheritance)

2.2 In OpenAccess ORM you will have a single object – OpenAccessContext, which you will use for all of your CRUD operations. It implicitly takes care of your transactions by accumulating the changes and applying them to the database when you call the method SaveChanges(). 

2.3 With OpenAccess ORM you will still have the flexibility of loading some properties and not loading others, we are offering several different approaches to define that, both on the context level and while configuring data binding.

2.4 This should not be a problem.

2.5 We do have caching mechanisms, so when you are exporting data that is already loaded in-memory there will be no database query 

3.1 There is no way to estimate this with exact measures, since there are too many variables to consider. I would recommend you to download the trial, reverse map your database in a simple class library and try moving things around on the Visual Designer (this is a relatively simple procedure, shown on this video). This is the only approach for you to have a clear idea of how the particular database model will perform on your development machine.

3.2 You are probably referring to the inheritance capabilities explained in 2.1 (let us know if you have something else in mind)

3.3 We are trying to keep the upgrades as painless as possible, but to be honest in some particular cases there might be issues. For that purpose we will soon start preparing a thorough Upgrade FAQ collection, which will cover most of the issues you might experience. 

I hope this information is helpful. I recommend you to get hands on with the product as soon as possible, since this is the best way to get a feeling of what we are offering. 

Do not hesitate to contact us for further details in the areas you are interested in.

All the best,

Ivailo
the Telerik team

[G W]

Thank you for your amazing answer.  It does make me feel good about your product, I will definitely reverse map our database and see what other things might come up with our specific situation.

One other question I thought of is that i wondered how well you'd support properties generated based off other properties.  For a simple example in the database there might be "CustomerFirstName" and "CustomerLastName" could i have a property in code that is "CustomerFullName" which combines the two?
Or summing all the Costs of a number of sub-objects.

 
I’m curious as to what the underlying technology of OpenAccess ORM is?  Is it built ontop of either Linq-2-Sql or Entity Framework?  Or something else?  I have yet to look much into building anything like it so I'm not even sure if that is the question i should be asking.

 

I think all the rest of my questions and concerns will be answered best by trying out the tool really, but I'll try to explain my original question just in case you have any insight:

1.2: Thinking about this question more, I guess my point is trying to get an idea of how many hours it is going to take to port over the application.  Which obviously depends mostly on the specific code, so I’ll probably just have to try to convert a page or two and see how it goes.  And either way converting it to use a solution that supports Linq will be more than worth it.

I was wondering when most of my methods are like:

public List<string> GetCustomers()

{

CustomersDataAdaptor da = new CustomersDataAdaptor();

Using (CustomersDataSet ds = new CustomersDataSet())

{

List<string> customers = new List<string>();

Foreach(…) customers.Add(ds.CustomerName);

}

return customers;

}

How many changes will that need, and what is the chance there is a way to simplify those changes?

So the original question was wondering if I could automatically replace

“CustomersDataAdaptor da = new CustomersDataAdaptor();

Using (CustomersDataSet ds = new CustomersDataSet())

{“

With “OpenAccessContext db = new OpenAccessContext();” And clean up the code but hopefully not have to modify much of the code structure or properties, at first at least.

I’ve tried to avoid getting data by column names (ds[“CustomerName”]) so that should make it easier since I’d imagine you could only support getting a field by string name using reflection.

[Ivailo]

Hello G W,

Here are the answers:

1) Regarding the calculation of fields - on one hand, it is supported by defining manually additional properties in a partial class. On the other  hand, those properties will not be usable in LINQ statements as per the current OpenAccess ORM runtime capabilities.

2) OpenAccess ORM is not using the Microsoft ORM tools underneath 

3) For simple data retrieval like in your example, you have basically two options:
a. Directly use the OpenAccessContext. Once you instantiate it, you can just use context.Customers and you have the same functionality. Of course, for more complex queries you can write LINQ statements and retrieve complex data.
b. Replace the code within your methods with references to the context. This is achievable, but it will be better to manage the context as explained in this documentation article, rather than instantiate it every time. 

Have in mind that you will not be using the OpenAccessContext directly, but it's child class that can be automatically generated by our Visual Designer. The child class will already contain all the Domain Classes you need in your application. This means everything will be strongly typed and you will be using properties to access table columns and methods to execute stored procedures. There is no need to hard code strings for referring to the database.

I would recommend you to take a look at our SDK, it contains useful examples of how OpenAccess ORM is integrated in various kinds of applications, so you can use it as a source of patterns and best practices.

Regards,
Ivailo
the Telerik team