Enjoy NEO (.NET Entity Object), the simple powerfull adaptable ORM for Agile development

Posted Apr 19 2006, 01:51 AM by Arif.Budimartoyo  

During this half year in my outsource project, I feel very comfort with .NET Entity Object (NEO) as our ORM tools. It has a easy adaptable feature to cover most of dynamic project driven by Agile methodology, as we understand these should be as same as other ORM tools. With NEO, I can do 'Domain Driven' design implementation, make the entities relationship and responsibilities more clear.
NEO, as developed by opensource team (http://neo.codehaus.org/), can free downloaded as well as you can modify or add something that will match to your environment. Ex. You can add Neo.Transaction library implementation while the original Neo 1.3.2 didn't care with the transactions.
We have been tested Neo 1.3.2 successfully has no problem to access SQLExpress and SQL2005 as it just deal with the views and tables only.

Realized that during 6 months, currently 6 projects are almost finished in overlapping-run by 2 team (5 persons) in offshore model development. This successfully projects will be followed by current prospected projects. The schedules will be distributed soon to 1 additional country beside of 2 existing offshore team.

Since it was an old tools (if you refer to LinQ etc.), it stable enough to make proven and working project. Ofcourse to make money immediately.
Very exiting!

Share this post: | | | |
Filed under:

6 comment(s)

Comments

Arif.Budimartoyo said:

Interesting.

Is it okay for .NET 2.0?
The Neo.Transaction, how is it compared to System.Transactions?
What Pattern Neo used? Data Mapper or Metadata Mapping? If it's Metadata Mapping, where's the metadata? XML file like NHibernate or Attribute like DLinq? or we just don't care just like DevExpress XPO?
Does it use Reflection?

He..he.. banyak tanya ya?
# April 19, 2006 6:36 AM

Arif.Budimartoyo said:

As the ADO.NET fully compatible, ofcourse NEO follow the raising of .NET 2.0 . The upcoming NEO2005 still in preview phase.
http://weblogs.asp.net/pgielens/archive/2006/04/15/443017.aspx .
There are a lot of adjustment in template generator to cover generics, partial classes, and nullable types.
And I believe there will be launched soon.

The Neo.Transaction was required before System.Transaction has been launched. And it just a add-on class and not being package in Neo source as it need while some dev required to implement MSMQ /Queing solution using Neo. It used declarative Transaction and implement COM+ support inside them. While actually we just need to place TransactionAware attribute to our class. The idea was taken from http://people.apache.org/~hammett/articles/dotnettransactions.html.
With System.Transaction, I believe all the problem will be covered better. Thats why Neo team didn't included Transaction in the 1.4 version.

Neo use Metadata Mapping as using the xml file of database representation (usually I generate this domain.xml using codesmith). And from this xml file, we use custom tool (NeoVsTool.dll) to make auto generation of all entity classes required (entitylist, entityfactory, entitybase, entitymap, entityrelation) while it saved.
No need of Reflection to create such objects as all of the classes are generated in the codeline.

# April 19, 2006 10:03 PM

Arif.Budimartoyo said:

Please find the sample code of Neo implementation here http://blogs.netindonesia.net/arif.budimartoyo/articles/9421.aspx

# April 25, 2006 2:25 AM

Arif.Budimartoyo said:

I use NEO as well, but I have to say that I encounter some problem with it.

1. I can't find a way to do aggregate query (e.g.: sum, count, avg) in NEO. I wonder if we could? We have inssuficient resource available for NEO anyway.

2. I have difficulty in determining the best practice for its concept of ObjectContext. In its example, it uses one object context for whole application, which obviously won't work in real world. Uses many contexts in the application is even trickier. We cannot know exactly what entities are saved when we call entitiy.Context.SaveChanges();.. Moreover, uses multiple context can potentially cause runtime exception on executing following line: book.Author = author (if they are of different contexts, this causes exception)

3. I have difficulty in applying it in distributed environment. Each entity is a heavy data object which is not serializable. Worse, it contains ObjectContext which is clearly not a suitable object to share accross processes. I'm very interested if anyone has used NEO for distributed / client-server environment.
# August 16, 2006 3:50 AM

Arif.Budimartoyo said:

1. You can use aggregate and calculation by iterating the ObjectListBase implementation. Otherwise, you can implement view then make it as table.

2. Make query from entity's responsible. Then you will have a Context responsibility. And do saving by always in the same Context. Ex: use PurchaseOrder.GetObject(POID), then from the instance objPurchaseOrder.GetPurchaseOrderDetailList() by using this.PurchaseOrderDetailRef as the Relation object then you get one Context to maintain Header /Detail entities.

3. You can use its entity's Context.DataSet to do serialization, otherwise you can build XML string from the collection then transfer it to the wire as data and schema as SOA implementation is to share the schema instead of classes.
I have been using Neo on Distributed apps. Rich client implementation and Transaction aware.

cheers,
# August 17, 2006 12:16 AM

Arif.Budimartoyo said:

Waduh papi bikin tambah mumet aja.... :D
# August 18, 2006 8:26 PM