What will be the high-level design of OPF? With abstract business classes or not? With IL or source code enhancement? Or else?
CocoBase, a commercial Java ORM tool has interesting ideas, proxy classes, which wrap the business classes ... the URL is http://www.thoughtinc.com, after registering you can download a lot of pdf documentation ....
Scott Amblers Web Site For Object-Oriented Developers
The Design of a Robust Persistence Layer for Relational Databases
A complete framework, that already several products implemented (being some of them open source). It's similiar to what we know about OS, dispite the fact that this paper talks about a lot more things to be implemented.
Its a classic material with a lot of patterns about Object Relational Mapping It culd help us with the archtecture and terminology: ftp://members.aol.com/kgb1001001/Chasms/tutorial.pdf
The above link is a presentation link the right link is:ftp://members.aol.com/kgb1001001/Chasms/chasms.pdf
Martin Fowler also have some materials and I think he is the first guy to talk about persistence with some examples in .NET :http://martinfowler.com/isa/OR-mapping.html
Other material that worth taeke a lok is the on-line documentation of TopLink:http://otn.oracle.com/docs/products/ias/doc_library/90200doc_otn/web.htm
*** OPF.NET Architecture Proposal [With some english erros! :) ] ***
I think that all of us are here becouse we one day made the same questions?
- How we will persist my Domain Objects in an aplication developed using .NET Framework?
- Can I wait until Microsfot or other enterprise develop a persistence Framework?
- Can I develop my aplications with ObjectSpaces in mind and pray that the mile-stone
for an release of it satisfy my schedule?
- Culd I implement it myself without loose my sanity?
- Shuld I take another Aspirin :) ?
The question is how to solve our problem in a way that satisfy the expectation that all
of us have in mind. What I pretend heare is expose an draft about how to resolve my
expectations and I hope it can help us to define our requirements and future mile-stones.
* Objectives *
** Develop an micro-kernel of an persistence framework that culd be used by itself. **
If you are java developer or like me just taked a look in how open-source persistence
framework deal with persitence you will see a lot of projects that take the same aproach
but dont share the same code. There is just one open-source persistence framework that use
this aproach(at least that I know) ObjectRelactionalBridge(ORB) that implemented an micro-kernel
that culd be used (after some refactoring) to implement the ODBG api and know is implementig
the JDO specification. This way we culd have an functional framework as soon as possible and
create an culture that culd make the core of our framework very robust.
** Give suport to much high-levels apis like ObjectSpaces(Final), OPF.NET in an second stage
or any other open-source Framework.
I dont know how ObjectSpaces will look like, I dont now if it will be free(I thik it will)
or payed, I dont now if it will be so intrusive(I realy hope not) but I think that as the Beta of
ObjectSpaces arrive we need to impement it Api, why?
*** Fist becouse this way we will be mitigating our risks. ***
Develop an persistence framework that culd be used in an real aplication is a very hard work
and as soon as Microsoft release an Beta of ObjectSpaces we culd see an API very near to final
release our risk will be the schedule to final release but if we implement the ObjectSpace api
we culd have our aplication working in open version of ObjectSpace that culd be not be good
enough to Microsoft final release but culd be good enough to our requirements and the schedule
of ours aplications will not depending on final release of ObjectSpace and besides as soon as
ObjectSpaces final release arrive we culd migrate our aplication without any modification.
*** Second we culd colaborate and with mono Project and better culd have some colaboration of it ***
More one time I will take ObjectRelationalBridge as an reference. At least Theo know that it is
now part of jakarta project and be adopted by an large project is a good thing and belive me
the final release of ojb will be the best open source implementation of an persitence framework in
java world with JDO implementation, integration with jakarta, JBoss.
The big question heare is wy jakarta adopted ojb? I thing it was becouse the architecture that
they use if micro-kernel that turn much easier implementing JDO specification than others.
As soon as Microsoft release ObjectSpaces what we will do with this work??? A like to think that
it will not be a waist of time and can be used to colaborate to see my aplications runnig in other
plataforms like Linux, Unix and MacOs.
** micro-kernel Architecture **
I will expose how I think the arquitecture of OPF.NET may be divide in and how culd it implemented.
That is just a suggestion and I suppose all of you have something like that in mind they are features
that IMHO culd be used to became our requirements.
*** Opf.Provider - The Abstraction of Relational Database ***
One feature that I supposed all of you have in mind is that we need suport at least two DBMS Oracle
DBMS SQLServer but support ODBC provider OLEDB will be good too. So heare we culd use an
Abstract Factory Pattern to abstract the provider that we use. This family of objects will be responsable
to tell us if some feature is supported by the provider that we are using, how to generate SQL (some
variations of sitax) and things like that. In the first stage support SQLSERVER is enought to me.
There is nothing new heare ObjectSpaces do this to abstract the Adapter and microsoft make the interfaces
in Provider with this in mind.
*** Opf.Map - The Object Relational Model ***
Heare we will have an Object Model that will tell us how to map our objects to tables in the DataBase or
XML file. I prefere to think in this model public cause its will make more easy to make an Mapping Tool and
until that we can use it to generate the xml that maps our types.
In the ObjectSpaces microsoft make this Object Model as internal but I think it will be much
usefull If they are public like in TopLink.
*** Opf.Query - The Query Framework ***
Heare using the Obect Relational Model and the Provider we will generate the SQL to do what we want. Heare
in the fists stage we will use the Interpreter Pattern to to generate the SQL. In think that we culd use the
interpreter pattern in the micro-kernel and add the tokens as we need.
We can use it to support in an second stage Opath, OQL or other query language. The problem with query
languages is that we will need to use an compiler compiler and there are no good compiler compiler to c# until
now, even the jay(the compiler compiler used in mono) is not good enought.
*** Opf.Transaction - The abstraction of the Transaction Engine ***
Maybe it is good idea keep the transaction engine isolated couse we culd need suport external transaction
manager to support ComponentService and in the future transaction in WebServices. We culd have pug-in patterns
with some pug-in interfaces heare.
*** Opf.Cache ***
The cache culd be used to improve performance. We culd use weak reference heare. This is an point were we will
nedd to talk a lot. If we use the aproached used by ObjectSpaces we use the DataSet as an abstraction of XML/DBMS.
*** Opf.Profile ***
We will need to develop an profile since the beginnig. The profile will be very useful to set-up the performance
of Opf by the DBA.
*** Opf.Log ****
The log will be very usefull to see how the sql was generated and corect bugs in the development stage of Opf
and to debug it in production. Heare use the log4net (ported from log4j) will be great!!!
*** Opf - The Broker ***
And finaly the Faced that will help to isolate the Opf.Net internal to the client ( our aplications in the fist
stage and an more sofisticate API in the second.
*** Concusion ***
The big question heare I think is if we will be compatible with ObjectSapces or not (this will limit how
will implement our micro-kernel) and you what do you think about that ? What is your expectation??? What you
have in mind.
Hi Mauro, seems like you have been reading my mind! One addition to the "database abstraction": I I also want to abstract the ADO.NET stuff, so our framework abstracts some of the "tricky .Net" libraries.
I have even considered writing the framework in J#, just to make it Java 1.1.4 compatible, but I don't think that's the way to go.
I will setup an initial VS.NET solution with the suggested subprojects (module "src").
Next step in my opinion would be the definition of the interfaces between the subprojects. I'll see if I can upload some UML diagrams on the homepage.
Can you explain what this MicroKernel is etc.Also before we start, I think that we should have clear understanding of the path we'll follow - so far only abstract goals and nothing concrete.
I suggest to follow the design concepts in Hibernate, that is use of reflection and compiled mappings.
By defining interfaces we're able to split up the project. It's also a way of abstracting implementation details, like having mapping attributes or an Xml repository.
* define high-level interfaces per sub module
* define goals per module
* implement stubs for interfaces so we can create NUnit tests
Well, I think we have to first agree on the design approach and after that start defining interfaces and modules. So far I haven't seen an explicit agreement on this question. And things seem to be moving very slowly, as there is avg 1 post/day in this discussion.
Lets go Deyan, what feature you want talk about first?
1) Which approach shall we use
1.1) abstract business classes (ala ObjectSpaces)
1.2) source/bytecode enhancement (ala JDO)
1.3) optimal use of reflection (Hibernate - 10x Theo for the url hibernate.sourceforge.net)
I vote for 1.3) - it is the least obtrusive to the domain model approach, the overhead is not big (Hibernate is the prove)
2) Shall we use mapping attributes in the domain model, external xml mapping or both?
I vote for external xml mapping files ONLY.
Let's see now what you think...
Guys, I have created 2 threads for voting ;-)
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.