Question
Is there a commonly used framework for AIR that handles mapping objects to and from the built-in SQLite database? An Annotation-based ORM framework that is to AIR what Hibernate is to Java?
Background
We have an AIR application that runs offline. I need to save/restore complex objects to/from the SQLite database. Some of these ValueObjects contain references to other ValueObjects. For example, an Order object contains a Customer object which contains an Address object.
Ultimately, I'd like to add metadata to my objects, like an [Entity] tag and have persistence "just work," with minimal configuration. I could roll my own ORM solution, effectively writing "Hibernate for AIR" myself, but SURELY someone has already done this.
I've read related posts like Best practices for developing AIR Application with SQLite that advocate creating DAO's, Builders and Services. That's a fine solution but, of course, no one wants to reinvent the wheel if it's not 100% necessary.
Candidates
So far, the best I could find is partial solutions. I'll keep a running list here:
SOFA from Matsiya
Technology - seems like it never got off the ground
FlexORM on RIAForge - seems dead, judging by the forum
JazzRecord - is a JavaScript solution that claims to work with Adobe AIR but documentation is sparse
Cairngorm Persistence Library - I hear nothing but bad things about cairngorm & this solution adopts the iBATIS approach, which is not like hibernate
AIR ORM in ColdFusion - not sure if this can be used without coldfusion (if so where do you get cfair.swc)?
Has a framework emerged for this? Specifically, I'm seeking one like Hibernate that uses Annotations/Metatags to map objects to tables. Are one of the candidates above actually acceptable?
What are you using succesfully?
All input is welcome. Thanks!
take a look at FxORM. I worked on a couple of AIR projects with it - it worked fine for quite complex data structure.
Take a look to AS3 SPOd, we use it on a daily basis on a rather large project. No problems so far.
Related
This is my first question on SO, so please bear with any mistakes/irregularities.
I wanted to implement SPA for my new project, Hence I reached Steve Sandersion's after some googling blog.
Looking at the code hosted on github, I noticed that I had to use EF to use Upshot, but my DAL is already written in Linq to Sql, which will be very tiresome to migrate to EF.
So my questions are as below
Has anyone successfully used upshot with L2S? If yes some example would help.
Is there any other way to implement the SPA without upshot so that I can reuse my DAL in L2S?
Edited
I just found today that this question stands useless, as using upshot will not be feasible. Microsoft has stopped working on Upshot.Some one please close this question.
I don't think it is possible. Microsoft has made it sure that people using Linq-to-sql don't survive.
Better use something like jquery and web api with some js mvvm libraries.
As far as I know this should be possible. When using upshot you don't need to use entity framework, you can do the wireing for your self.
In my ria 4 html demo, I make use of ria services to get the data from the server to the upshot client. This way it doesn't depend on the DAL you have. Ria services works by conventions, meaning insert, update and remove methods are present on every domaincontext and you can implement them as you want. For more info you can read this blogpost on setting everything up. And this on for the CRUD operations.
A new requirement has come down from the top: implement 'proprietary business tech' with the awesome, resilient Elixir database I have set up. I've tried a lot of different things, such as creating an implib from the provided interop DLL (which apparently doesn't work like COM dlls) which didn't work at all. CPython doesn't like the MFC stuff either, so all attempts to create a Python lib have failed (using C anyway, not sure you can create a python library from .NET directly).
The only saving grace is the developer saw fit to provide VBA, .NET and MFC Interop C++ hooks into his library, so there are "some" choices, though they all ultimately lead back to the same framework. What would be the best method to:
A) Keep my model definitions in one place, in one language (Python/Elixir/SQLAlchemy)
B) Have this new .NET access the models without resorting to brittle, hard-coded SQL.
Any and all suggestions are welcome.
After a day or so of deliberation, I'm attempting to load the new business module in IronPython. Although I don't really want to introduce to python interpreters into my environment, I think that this will be the glue I need to get this done efficiently.
I tried out EF back in .NET 3.5 SP1, and I was one of the many who got frustrated and decided to learn LINQ to SQL instead. Now that I know EF is the "chosen" path forward, plus EF 4.0 has some exciting new features, I'd like to migrate my app to EF 4.0.
Can anyone suggest any good resources that are specifically targeted towards 4.0 and L2S migration? NOTE: I can find plenty of blogs and articles related to migrating from L2S to EF on .NET 3.5, but I feel like many of those were obviously dated and unhelpful to someone using 4.0.
I'd really like as much deep, under-the-hood stuff as I can get; I want to really come away feeling like I know EF 4.0 the way I currently know L2S 3.5.
TIA!
I have done loads of this very type of conversion and FWIW, I would say there are more similarities than differences. I don't think there is any definitive documentation that will make you feel like an expert in EF4, beyond the stuff that is already out there...
http://msdn.microsoft.com/en-us/library/ex6y04yf(VS.100).aspx
What I can give you are the more obvious "gotchas." Specifically, Linq2Sql wanted to combine the business layer and the data layer a lot more obviously. It really pushed you to create your own partial classes. I could go on and on about way, but the most specific reason is the way the one-to-one mapper will create public parent and child properties for all relations.
If you attempt to use any type of serialization against this model, you will like run into circular reference problems as a serializer moves from a parent to a child and then back to the parent as the Linq2Sql serialization behavior automatically includes all children in the graph. This can also be really annoying when you try to grab a customer record to check the "Name" property and automatically get all the related order records included in the graph. You can set these parent and child navigation properties to be either "public" or "internal" which means if you want access to them, but don't want the serializers to automatically create circular references, you pretty much have to access them in partial classes.
Once you start down the partial class path you generally just continue the pattern and eventually will start to add helper methods for accessing your data into your individual entity classes. Also, with the Linq2Sql DataContext being more lightweight, you often find people using some kind of Singleton pattern or Repository pattern for their context. You don't see this as much at all with EF 3.5 / 4.
So let's say you have some environment similar to the one described and you want to start converting. Well, you need to find out when your DataContext is going to be create/destroyed...some people will just start each Business Layer method with a using() statement and let the context pretty much live for the lifetime of the method. Obviously this means you can get into some hairy situations that require adding .ToList() or some other extension method to the ends of your questions you can have a fully in-memory collection of your objects to pass to a child method or whatever and even then you can have problems with attempting to update entities on a context that they weren't originally retrieved from.
You'll also need to figure out how to much of the BusinessLogic incorporated in your Linq2Sql partial classes out into another layer if it doesn't deal explicitly with the data operations. This will not be painless as you figure out when you need/don't need your context, but it is for the best..
Next, you will want to deal with the object graph situation. Because of the difference in the way lazy-loading works (they made this configurable in EF 4.0 to make it behave more like Linq2Sql for those who wanted it) you will probably need to check any implied uses of child objects in the graph from your Linq2Sql implementation and verify that it doesn't now require an explicit .Include() or a .Load() to get the child objects in the graph.
Finally, you will need to decide on a serialization solution in general. By default, the DataContracts and DataMember attributes that are generated as part of an EF model work great with WCF, but not at all great with the XmlSerializer used for things like old .asmx WebServices. Even in this circumstance you might be able to get away with it if you never need to serialize child objects over the wire. Since that usually isn't the case, you are going to want to move to WCF if you have a more SOA, which will add a whole new host of opportunies, yet headaches.
In order to deal with the partial classes situation, and the hefty DataContext and even the serialization issues, there are a number of new code-generation templates available with EF 4.0. The POCO-Entity template has a lot of people excited as it creates POCO classes, just as you'd expect (the trouble is that excludes any class or member attributes for WCF etc etc). Also, the Self-Tracking Entities model pretty much solves the context issue, because you can pass your entities around and let them remember when and how they were updated, so you can create/dispose your contexts much more freely (like Linq2Sql). As another bonus, this template is the go-to template for WCF or anything that builds on WCF like RIA Services or WCF Data Services, so they have the [DataContract], [DataMember], and [KnownType] attributes already figured out.
Here is a link to the POCO template (not included out of the box):
(EDIT: I cannot post two hyperlinks, so just visit the visualstudio gallery website and search for "ADO.NET C# POCO Entity Generator")
Be sure to read the link on the ADO.net team blog about implementing this. You might like the bit about splitting your context and your entities into separate projects/assemblies if you fall into the WebService vs. WCF Service category. The "Add Service Reference..." proxy generation doesn't do namespaces the same way "Add Web Reference..." used to, so you might like to actually reference your entity class assembly in your client app so you can "exclude types from reference libraries" or whatever on your service references so you don't get a lot of ambiguous references from multiple services which use the same EF model and expose those entities...
I know this is long and rambling, but these little gotchas were waaay more of an issue for me than remembering to use context.EntityCollection.AddObject() instead of context.EntityCollection.InsertOnSubmit() and context.SaveChanges() instead of context.SubmitChanges()...
For EF Code First, it's mostly about reverse engineering the existing tables into EF classes. EF Power Tools now does this for you:
http://msdn.microsoft.com/en-us/data/jj200620.aspx
The rest is the obvious work of modifying your existing code to use those generated classes to talk to the database instead of LINQ to SQL.
I'm trying to find a way to generate Linq to SQL classes with bi-directional serialization attributes. Basically I want a DataMember tag (with an appropriate order) on every association property, not just the ones where the class is the primary key (like the Visual Studio generator and SQL Metal do). I checked MyGeneration, but didn't really find anything that worked for me. I thought the T4 Toolbox was going to be my solution, it would be quite easy to modify it to add the attributes, but I get an exception on the calling side of my WCF service, and I've gotten no response back on the issue. I'm about to try installing CodeSmith and using PLINQO, but I'd prefer something free.
I'm pretty close to just writing my own T4 generator, but before I do that, I was hoping to find an pre-built solution to this rather simple problem first.
I ended up writing my own code generator for our L2S classes. We actually generate two sets of classes. One is a "lightweight" set of entities for client application use. These classes have no L2S plumbing. But they have the full datamember attributes with proper order. Then we have our L2S entities, which are strictly for backend use. This has worked out quite well.
Be careful using PLINQO. I've looked at that product extensively. In fact, much of my code generator is based on the code PLINQO generates. However, they have a "major flaw" (their words) in how they have implemented many to many relationships.
You might want to also look at a product named "Reegenerator".
Randy
This turned out to be the solution to my problem. I had just resigned myself to start researching my own generator when I stumbled upon that. It has a bidirectional serialization option and it works great! Here's a link to the author's bog, which contains a great video example of how to get started.
I keep hearing that Lisp is a really productive language, and I'm enjoying SICP. Still, I'm missing something useful that would let me replace PHP for server-side database interaction in web applications.
Is there something like PHP's PDO library for Lisp or Arc or Scheme or one of the dialects?
newLisp has support for mysql5 and if you look at the mysql5 function calls, you'll see that it's close to PDO.
Since nobody has mentioned it, you can try Postmodern, which is an interface to PostgreSQL. It aims for a tighter integration with PostgreSQL and so doesn't pretend to portability between databases.
I've put it together with hunchentoot and cl-who and built a pretty nice website.
newLISP - http://www.newlisp.org/ - has support for MySQL, but I haven't used it (newLISP).
If you're happy with SQL as part of your life, CL-SQL provides a mapping into CLOS objects. It appears to be more mature than Elephant.
I'm using it on my own website.
I've had good success with SBCL and CL-SQL. CL-SQL has a object mapping API, but I used the plain SQL API which simply returns lists and this worked well enough. And in the Clojure language, you interact with JDBC through a maps or structs {:col1 "a", :col2 "b"}, so a generated class library doesn't get you any simpler code, the language handles it nicely. In my experience, there is less cruft between lisp and sql than between more static languages and sql.
our Common Lisp ORM solution is http://common-lisp.net/project/cl-perec/
the underlying SQL lib is http://common-lisp.net/project/cl-rdbms/ (fully tested with PostgreSQL, has a toy SQlite backend and a somewhat tested Oracle backend)
we started out using CLSQL, but after some struggle we decided to roll our own.
these libs and PostgreSQL are used in a clustered web application developed for the Hungarian government for planning the budget of the municipalities. it has about 4000 users, 500 at peek time. a little more info is available at http://common-lisp.net/project/cl-dwim/
Cliki is a good resource for Common Lisp libraries:
http://www.cliki.net/database
There is a project named Elephant (http://common-lisp.net/project/elephant/index.html), which is an abstraction for object persistence in CL.
As long as you're switching your Webapp on Lisp, consider using persistence: you now have a constantly running Lisp image that holds everything about your application. I personnally used Elephant for that.
Elephant can use CL-SQL or BDB as it's backend, which means that you can use MySQL if you have one running. I found using SQLite really practical, though.
We use SBCL, UCW, CL-SQL and MySQL as our back-end for Paragent.com. It has worked very well for us. We also have a number of clients using UCW/CL-SQL/MySQL for custom sites we have built them through our consulting arm Bitfauna.