|
|
Why ObjectGOO |
|
Near Zero Configuration
|
|
Persist Objects in SQL in Minutes
|
|
No Config Files (Did I already say that)
|
|
Partial Persitance Normalization
|
|
Its Free
|
|
Its Open Source
|
|
Retrieve objects using SQL
|
|
Auto reconfigures views for reporting
|
|
|
|
Status
|
|
ObjectGOO is PRE-Alpha, I have decided to release a Demo
project as the methods and interfaces wont change only be added to and revised for
performance and Oracle compatiblity. A Subversion repository and Forge should be
available by months end if you wish to help.
|
|
Oddities
|
|
ObjectGOO has an unusual side effect, it is actually FASTER at retrieval and population of Datasets than native ADO.Net.
Reason: Because the way objects are deserialized into XML they translate to create a dataset much faster than retrieval from a flat structure then into XML.
Odd but true.....
|
|
|
|
|
ObjectGOO has landed (Continued....)
|
 With a splat
for now lets say. Well sort of, I have decided after much prodding and pushing to
relase a proof of concept demo. I have decided to release an earlier and (sort of)
working demo.
I will be posting the code for ObjectGOO itself shortly, Im in the middle of a teardown,
the version (released only as a dll (all 48kb) turns SQL 2005 into an Object Database.
I was tired of writing (or having junior developers) write SQL maps for IBatis and
the like for prototyping and training, so ObjectGOO was Born.
I coded the original implementation in an evening, the second in 2 days, its lightweight
uses no config files and Will persist objects, Collections, Etc, using deep serialization.
The MS entity framework will be integrated as well as LINQ when released but realize
ObjectGOO is MUCH MUCH simpler to use and implement, it does all the "dirty work"
on the Downside it currently only works with SQL 2005-2008, Oracle support is in
the works and partially complete.
Everything is strored in a common table structure. ( A Seperate table for each object
)
BUT it is automagically exposed as a flattened view for Reporting, Query, etc like
so....
So say a Person has a collection of addresses , I can persist either the person
or the whole domain chain.....
With one line of code.
The Final Line in the below code example.
Actions.ExportDomain(g)
The last line will Create the table if it dosent exits, as well as a flattened view
for reporting and well thats all you need to do to create George. (Our Person)
(All presented in "Longhand" using a blank consturctor)
Dim
g As Person =
New Person
g.FirstName
= "George"
g.LastName
= "Someone"
g.Gender
= "Male"
g.Adresses
= New GBOCollection(Of Address)
'Lets
add an address
Dim
ad As Address = New Address
ad.StreetAddress
= "1313 Mockingbird Lane"
ad.City
= "SomeCity"
ad.State
= "Ohio"
ad.Zip
= "44444"
g.Adresses.Add(ad)
'Now
lets save George
Actions.ExportDomain(g)
'Thats
All we need to do to save George, please save George he needs our help......
|
If we already have George and we want to Save him and he already exists it automatically
makes it an update, if not he gets inserted. OH, and it will clone anything, even
Objects that dont implement IClonable interface.
If the Person Object has changed NO PROBLEM, it will ignore any unused fields, and
it will extend the view (when the App Setting is set to Development) , no data is
lost and you can extend objects during the devlopment phase without database
re-work.
I Can Get the Person Via ID , SQL
, as an Object, as Raw XML, as a part of a collection or as a Dataset
Whereas there
is an address DataTable and Person DataTable in the dataset. With One Line of code.......
Like so.........
Dim
ds As DataSet = New DataSet
ds = Actions.ImportDomain(New
SqlClient.SqlCommand("Select * from
[vw_BaseObjects.Person]")) |
|
|
Other ways George can be pulled are as follows....
Dim
g As Person =
New Person
g = Actions.ImportDomain(New
SqlClient.SqlCommand("Select * from
[vw_BaseObjects.Person] where [FirstName] = 'George';"),
g)
'Or
Shorthand we could just do
'Dim
g As Person = Actions.ImportDomain(New SqlClient.SqlCommand("Select * from
[vw_BaseObjects.Person] where [FirstName] = 'George';"), g)
'Or
if we had his GUID we Could
'Dim
g As Person = Actions.ImportDomain("6721e28e-2803-412f-bbfb-1f41d8eeac28", g)
'Or
Put him in a collection witl all the people in the table
'
Dim coll As GBOCollection(Of Person) = New GBOCollection(Of Person)
'coll
= Actions.ImportDomain(New SqlClient.SqlCommand("Select * from [vw_BaseObjects.Person]"),
g, coll)
'Or
fill a dataset with all the associated tables.
'Dim
ds As DataSet = New DataSet
'ds
= Actions.ImportDomain(New SqlClient.SqlCommand("Select * from [vw_BaseObjects.Person]"))
'Or
get the RawXML
'Actions.GetObjectXml(g) |
For more examples download the Demo Solution.........
Object
Goo was meant to totally abstract the Object and Data layer from the code, I have
coded projects using ObjectGOO (in a production enviroment) without ever looking
at the database. And saved about 70% of the time coding.
And So on....Download the
Demo project and see for yourself all basic functions are covered. ObjectGOO is
far from perfect but after using NHibernate, IBatis, and Just about every other
ORM/Mapper and Object persistance layer out there, I killed all the things I didnt
like (Mostly the Configuration and Mappings) and kept the ones I did, maybe you will like it too. |
|
|
Known Issues
|
|
LOTS ! Its Pre-Alpha code.
Inserts are in the Demo only Single Threaded. (Last version to pass NUnit tests
100%)
SQL Parsing 85% complete must use * on selects.
ENUM persistance broke somewhere along the line while threading.
.....Trust me there are more, did I say PRE-Alpha ?
|
|
Requirements
|
|
SQL 2005 or (SQL 2005 Express Installed)
PWS, or IIS (for Demo)
.Net 2.0 or Greater framework (Tested up to 3.5 beta 2 and SQL 2008 Beta/RC)
|
|
Whats Coming.....
|
|
Multithreaded Inserts
Bulk Inserts
DataTable, as well as many IBatis style overloads for object retrieval options.
LINQ Integration.
Lazy Loading of large collections
|
|