I have been reading this white-paper by Scott Ambler. He provides a fairly detailed description and some diagrams in UML of a persistence layer which uses reflection and class-maps to completely abstract
db schema from object schema and automatically generate all SQL. Sounds like the real deal - ie. what a lot of us have been looking for. Unfortunately, I have do not have the time nor the skills (yet ;)) to implement this layer based solely on UML and a white-paper.
I was wondering if anyone has attempted to implement the described solution in .NET and, if they have, would they care to share the code? I realize the described Robust Persistence Layer is very similar to one or two of the currently available commercial mapping
products (or is it?). At any rate, I would also appreciate any discussion of Mr. Ambler's model. Thanks!
yes.. there tons of implementations out there. most are in java, but several are in .net. take a look on sourceforge.. search for .net o/r or .net persistence. you'll find a few there... they all have their flaw tho. sadly most of the .net ones have been ported
from java and not designed from the ground up specifically for .net.
I would be willing to bet that most, if not all, persistence layer implementors have read his papers. What I don't like about his solution is that he seems to use an abstract base class (PersistentObject) for his domain classes. This is a Layer Supertype and
not very flexible. I think its more instructive to study JDO to look at a real implementation of a Persistence Layer than this stuff.
::I think its more instructive to study JDO Great idea. JDO normally suggests using bytecode mangling at class load time. Definitly the best solution. Now comes the hard part: try doing this in .NET. Why? Not possible. Case closed.
Its possible. As I think I've mentioned to you before, I wrote a mapper without an abstract base class or bytecode mangling. BTW, thanks for mentioning JDO, Dave. I had never heard of it before. Just went to google and downloaded the spec. Very nice. I should
have been trying to follow its naming conventions for my mapper. I didn't realize there was a spec around (of course its just a java spec :-).
::As I think I've mentioned to you before, I wrote a mapper without an abstract base class ::or bytecode mangling. Yes, but reading the subject of this thread, this is a discussion abouta ROBUST persistence layer. ::Why is the abstract base class (layer supertype)
not well regarded in this context? his is something I dont understand either. I work with persistence layers for about 8 years now, an I hear this argument very often. But then, noone has ever been able to show me any need for using the inheritance class in
a way that was not compatible with the persistence layer. I ask everyone who comes up with the claim this is bad, and all I got so far was hot air and a childich "because it is bad". Noone ever was able to construct even a simple realistic sample where it
was blocking. Most come along the line "maybe I want to use some third party component as base class", and then fail to even come up with a single sample of what this could be. Business objects end up, somehow, inheriting from other business objects and that
is it. I consider a infrastructure base class perfect to handle a lot of items a business object should also handle (naturally, only if you dont want them to be totally stupid). These are things like databinding, XSL integration (eith the EntityBroker every
list returned and every object can be durectly used as source for an XSL transformation, which is sometimes VERY neat). I see this requirement similar to having "Page" as an infrastructure base class for ASP.NET pages etc. There are a ton of advantages in
addition to handle certain persistence details.
Lets say your vendor forces you to subclass all your business objects from BusinessObject, an abstract base class derived from Object. Then, you find out you want to use COM+ (need to subclass from ServicedComponent), or you find out you want to remote your
business objects (need to subclass from MarshalByReference or Component). It's just not flexible. In the Java world, they have a saying for this: POJO, plain old java object. With JDO, your business objects are POJO's. That's the kind of flexibility I want
in .NET.
1) The only thing that JDO and Scott Ambler approach have in common is that they are both Persistance Layers. From the practical level they are tottally different as they allow one to do different things with the Objects. 2) The Scott's BaseClass (PersistantObject)
is really annoying some times, but at the practical level it is not so especially when one is building a custom app. Most O/R Mappers allow one to implement a IPersistantObject Interface in order to circunavigate these problems. 3) Last time I've heard JDO
is having some problems but I can't state for a fact as I've never played with it. Nuno
Dave if you're interested I can send you a copy of my mapper. I've only spent a little time documenting it, but there are examples included which show the basic functionality. No BusinessObject class or PersistantObject interface. Send me an e-mail at gabe.halsmer@attbi.com.
I'm not sure when I'll be able to release it on a public web-site. I have a dedicated server I want to use for co-location, but unfortunately that machine is tied up doing other work. Maybe in a few months I'll have it set-up, and then it will be easy to download
a trial version.
@dfoderick: This is exactly what I called these little "irreal samples". ::Then, you find out you want to use COM+ (need to subclass from ServicedComponent), or ::you find out you want to remote your business objects (need to subclass from ::MarshalByReference
or Component). It's just not flexible. It is just a stupid bad implementation. EVERY O/R mapper should actually have a strong implication to inherit his base class from ContextBoundObject (reason: business objects ARE context bound, logically - they exist
in the context of a transaction) and remoting should also be handled from the persistence layer. So basically you dont describe a need to have a baseclass. Any more realistic example?
Don't be so defensive. It basically boils down to this. Someone writes class X without any intention of persisting it. Someone else wants to create a new class Y that inherit from X. This other persons wants to persist Y without having to bug the author of
X to change what they are doing. Why can't I decided to persist Y?
I am not defensive, I am realistic. Could you please try to come up with ONE realistic example? I hear this argiment for years, but noone has ever come up with any sample that is: * Concrete and * Valid It always boils down to "when I want the object to cook
coffee, too, it does not work". I never have found an object that I wanted to persist that was not prepared for persistence. Things dont work like this in reality - persistent objects are part of lager networks of objects, need to adhere to specific API's
anyway (validation, anyone?) and the bas class is just a non-issue. And I talk out of more then 8 years practical work - never has anyone put any substance behind exactly thie one argument you provide.
Are you being willfully ignorant? I know you are a smart guy, but I can never tell if your flashes of stupidity are real or an act. Let's consider a simple Domain model... Graph * has a width & height * has a collection of Nodes * has a collection of Edges
Node * has a symbol name * has an x and y position on the Graph Edge * has a reference to a "source" Node * has a reference to a "destination" Node Now I wrote my own classes for this domain model and used it in a few apps, even used my own mapper to persist
it. However, what if I had came across an API for a Graph class much better then mine. The data model would be about the same, but they had all kinds of better methods based on Graph theory that I never had time to write in my class. Now this original author
I've never meet, and I don't have his source. He never planned on his graph objects being persisted. If I want to use his Graph object, but still need it persisted, I'm going to need a mapper that doesn't care about that Graph object inheriting from some mapper's
base class. Agreed? There is an alternative. I could write a skeleton data class tied to a mapper, and move the data in-between my object and the API. But that's repetitive error-prone and boring code. Exactly the type of code a mapper should do away with.
Understand, I'm not saying its the end of the world if your mapper doesn't support this. But its useful. Its what the JDO spec had in mind. BTW, do you notice how you change your arguments thona? First it was "that's not possible, end of discussion". And then
when someone tells you it is possible, you switch "well, who would ever want it!"
::Are you being willfully ignorant? I know you are a smart guy, but I can never tell if your ::flashes of stupidity are real or an act. I am realistic, which is what you are missing here. ::However, what if I had came across an API for a Graph class much better
then mine The question is: DID you come acoss one? Real life example. Not some baby crying it does not get what it wants although it does not really get what it want anyway. Some real example where the inhertance tree WOULD HAVE LIMITED YOU. Some real one
where you said "great I did not have inheritance". I have an argument like yours: ASP.NET is utter total garbage because it requires a baase class. See, when I come across a much better set of controls, I can not use them when they are not compatible. Or when
I dont want to render web pages, it is totally useless. But who cares? I have another one: why do you have a girlfriend? You COULD meet the most wonderfull women of the planet, and then you are done. I will try to formulate it in a way that you can understand:
in the last 10 years NOONE has come up with even ONE situation where this "potential damage" actually DID happen. For more than 6 years in discussions I regularly get arguments like yours. And NEVER EVER did someone come up with a valid example. Now, what
is not valid in your example? Simple: id DID NOT HAPPEN. It is unreal. Now, naturally, you could just say "well, other people may be smarter than I and may have stumbeld over a situation where this is valid", but guess what: it did not happen so far. Fact
is that business objects that are persisted are normally nothing more than business objects that are persisted. They are persisted and interact with each other. There is NOTHING specific in the "way they interact" that would require any particular sophisticated
functionality that is NOT related to their business logic or the persistence. So your sample is not valid. It is actually, in my eyes, an exact sample that shows how NOT to program. I currently do something like what you do. We work on some graph visualisations.
Now - we have persisted classes in the graph, and we have this funy classes for visualizations. But guess what - I would never mix them. I would never put the visualization classes into the persisted objects. And now: this "more advanced graph API" that you
dream up absolutly does belong - into the visualization, and not into the persistence. In the persistence I can actually not hink of anything that is specific and would require what you would call a "more sophisticated API". The storage of the graph node data
is totally part of the business logic, and the storage of the graph "links" (or edges as you call them) is not something that requires and particular knowledge. There should be a second set of objects in the presentation layer that only deals with the presentation.
Now, you may actually consider this to be a bad argument, but it is a realistic one. EVERY tree view I know so far requires the content (nodes) to be inherited from tree specific class. And I would never come to the idea to inherit these classes and persist
them. Never. So, sadly, I can not really accept your example as valid. The question now is - are you, as the first person in the last 5-6 years that I wander around and talk to the people, and with about 300-400 people to which I have talked about this subject,
smart enough to come up with the first sample where a persistence layer base class would REALLY limit you? It would suprise me.
Soul I understand your point but from a practical level i'm not so sure if it is a differentiatior when comparing O/R Mapper (IMHO only a naive person would see it as a huge differentiator). OJB for instance supports both ways, but to tell you the truth most
people prefer the base class approach, it just handles a lot of things aitomatically that otherwise would have to be taken care by the programmer (for instance joining transactions automatically, etc etc), making the all experience with Business Objects more
"natural". Nuno
I don't think its a big differentiatior either, since in most situations you only need to persist classes you wrote. :: base class...handles a lot of things aitomatically that otherwise would :: have to be taken care by the programmer (for instance joining
transactions :: automatically, etc etc), I'm not sure what you mean. All that should be handled by the mapper. The domain class/object should be completely oblivous to it. I haven't tried at all of these other mappers. Sounds like a base class is the only
way they can solve their problems, though I don't understand why they have these problems in the first place. @thona :: I have another one: why do you have a girlfriend? You COULD meet :: the most wonderfull women of the planet, and then you are done. Out
of all your irrelavant analogies, I actually like this one. Well said. Though don't get me wrong. I'm not trying to preach you have to achieve some theoritical perfection or else its a toy. I'm a realist. But you said something was impossible when its not.
I only wanted to mention I've done it to avoid confusion in our industry about what are the limitations of O/R Mappers. I'm not a competiting vendor. I will probably never sell my mapper because I don't have the time to document it, or set-up a web-site, or
any of the other zillion things I'd need to do to sell a product. So, do chill.
::I'm not sure what you mean. All that should be handled by the mapper. The domain ::class/object should be completely oblivous to it. "SHould be"? Oblivious to things like exposing a standardised error reporting interface (as defined by the .NET framework)?
To things such as having a little bit an optimised change notification mechanism through a central PropertyChanged event? Nice. How do you do this? ::I haven't tried at all of these other mappers. Sounds like a base class is the only way they ::can solve their
problems, though I don't understand why they have these problems in the ::first place. Because they care about their code. Proxies are a great ay to do certain things, granted. Sadly, they are a runtime only feature, and as such are not really integrated into
the design process. Also, per definition of the TrueProxy class, the TrueProxy class (which is used in the .NET proxy mechanism) can not expose any method that is not part of the class being proxied. ::Though don't get me wrong. I'm not trying to preach you
have to achieve some theoritical ::perfection or else its a toy. I'm a realist. Given your success to come up with realistic samples, bear with me when I say that I simply dont buy this. ::But you said something was impossible when its not. I only wanted to
mention I've done it ::to avoid confusion in our industry about what are the limitations of O/R Mappers. But you failed greatly in actually mentioning and demonstrating what you have achieved. Your solution could and possibly is so full of limitations that
it is not viable. Without even just a download and a simple sample and some documentation around, saying what yoyu have done is of very little worth in a topic as complicated as an O/R mapper. Frankly, you have a lot of strength in resisting reality. Point
is that most O/R mappers go with base classes, and they do not do so for their limitations. When we started with the EntityBroker, I was seriously considering going wih a wrapper appraoch. Actually we DO go with a wraper appraoch now, but for other things
(optimising property get acces over a network). But I made the consious and well thought out decision that I (and a lot of customers have fallen in line) prefer to work with a well designed base class. And, and this is nothing more than reality, dear "Sould
of Reality", as I said, noone has ever been able to come up with a scenario in which the missing baseclass WAS a limitation. All you achieved was adding another one to this long list of failed attempts.
@Soul ":: I have another one: why do you have a girlfriend? You COULD meet :: the most wonderfull women of the planet, and then you are done. Out of all your irrelavant analogies, I actually like this one. Well said. " It was not me who did this analogie so
I can't really collect the merit for it if you know what I mean. "But you said something was impossible when its not. I only wanted to mention I've done it to avoid confusion in our industry about what are the limitations of O/R Mappers." I guess you are confusing
people. I have not said it was impossible. In fact I've stated a totally different thing. What I've said is that joining and removing objects from a transaction to be automatic the Domain Objects need to be aware of how to deal with this. But this does not
mean that the programmer of those DO's need to be aware of how to do it either, the base class handles this. Now one can simply not support this feature amongst others, and in this case there is no need for an Domain Object to inherit from a base class. Let
me provide you with these two peaces of code: 1) Domain Objects that inherit from a Persistance Aware base class [Transaction(TransactionOption.Required)] public class BusinessLogicFacade : ContextBoundObject { ....... public Planet CreateNewStarAndPlanet(string
starName, string planetName, decimal rotationalPeriod) { Star newStar = new Star(starName); return new Planet(newStar, planetName, rotationalPeriod); } } Both Star and Planet inherit from a PersistantAware base class. A transaction is created automatically
once the method CreateNewStartAndPlanet is calles, and both objects Star and Planet particpate in the transaction created. 1) Domain Objects that do not inherit from a Persistance Aware base class TransactionApiFactory facade = OJB.Instance; Database db =
facade.newDatabase(); db.open(Database_Fields.OPEN_READ_WRITE); Ojb.Net.Transaction.Api.Transaction tx = facade.newTransaction(); try { tx.begin(); Article example = new Article(); db.makePersistent(example); example.Stock = 333; example.addToStock(47); example.addToStock(7);
example.addToStock(4); tx.commit(); } catch (Exception ex) { tx.abort(); throw ex; } The Article Object is not PersistantAware. That, it does not inherit from any Persistant Aware base class. Enjoy, Nuno PS: I don't like to discuss things in abstract terms.
Basically every design decision is a compromise between flexibility and clarity. I have not shown the code for neither Domain Objects, but there is non apart from the fact the the PersistantAware classes inherit for a base class provided by the framework and
the Article does not.
@thona, " Proxies are a great ay to do certain things, granted. Sadly, they are a runtime only feature, and as such are not really integrated into the design process." Of course they aren't. They are supposed to be transparent to the design process of an application.
This is in fact their main benefit, but one can argue that is their main weakness too and I for one can also see that as a weakness too, granted. Nuno
Nuno, I switched from quoting you to quoting thona. Sorry for the confusion. I edited my post to inlude @thona. So what are you saying thona? That since I haven't posted my code, it must suck? Assume away. Like I said, I'm not selling it. This is merely an
educational forum in my view. Since you are selling a product, you have set your path and why would I want to change your thoughts on O/R Mappers? I mean let's be honest thona, you know everything about mappers anyway. Clearly you don't need to learn anything
else.
::I mean let's be honest thona, you know everything about mappers anyway. Clearly you ::don't need to learn anything else. This is absolutly wrong. I spend hours a week just looking for new stuff to learn. The difference is that I do this by striving along
people who have something to say. I scan regularly through cetus links, I spend a lot of time visiting and excaluating the nice little stuff about JDO, and tons of other stuff. But this does not mean that I have to listen to someone who has nothing to show
:-) Idf your stuff is for educational purposes, why dont you just upload it? Webservers are cheap, and making a little HTML page stating some generics takes less time than you spend trying to convince us you have a good solution.
@thona :: And, and this is nothing more than reality, dear "Sould of Reality", as I :: said, noone has ever been able to come up with a scenario in which the :: missing baseclass WAS a limitation. My dear thona, you should be able to see this from all I've
explained. I searched for a long time for a Graph class with all the methods I'd needed (like spacing out the nodes evenly using a KK Algorithm). Of course the data-model itself is very easy and I could write that, but I didn't want to have to write all that
mathematical code. Anyway, I never found a Graph class in .NET I could use (only java). So I had to get some research papers and write my own. But I kept this in mind when I wrote my mapper. And I had to, since I'm designing my mapper to not just do what I've
done in the past, but what I might do in the future. You have to have forethought in something this large. A mapper assumes a lot of responsibility and its very bad to discover down the road you can't use it because of some silly design limitation. Would you
agree?
Well, Soul, as I said: your design is broken as the layout functionality hould not never ever be part of the persisted classes. That simple. I have a similar situation here right now - for the EntityBroker 2004 we are going to add some minor UML like modelling
capabilities. Now, I DID find an API. It DOES require it's own baseclass. Now, is this compatible with the EntityBroker? Yes, absolutly. Because the persistence will never ever work with the graph nodes, but with objects beneath them. Is this overhead? Yes.
Is this bad design? No. Why? Guess. Because, simply, every persisted objects will actually have at least TWO DIFFERENT presentations anyway, so it will have two different "nodes" on top anyway (one for the graph, one for a tree), and these are both determined
by respectvie visualzation framework. They are not part of the business logic. So, your example is as relevant to the topic of persistence, in my eyes, as the toppings of the pizza I ate yesterday. Not at all. So, imho, there is no sense in remembering it.
Would you not agree? And this is why I just dont consider this example to be valid. Now, WOULD it be valid, you would see some significant changes in the EntityBroker being planned immediatly. Why? Because then I would, after many years, have a reason to abandon
the requirement for the base class. But then, it just does not happen with your example.
:: Webservers are cheap, and making a little HTML page stating some :: generics takes less time than you spend trying to convince us you have a good solution. Yeah soon. Once it get this server freed up, I'm putting it in co-location and then I can post my
VS.NET solutions for download.
::Yeah soon. Once it get this server freed up Well, if this is what is holding you back I can offer you a website for the time being. ASP.NET 1.1 on 2003 server, FTP upload and it is yours until you find the time to free your server.
:: takes less time than you spend trying to convince us you have a good solution. I would not waste my time trying to convince you of anything thona. You are narrow-minded, and you don't want to listen to anything but what you've created in your own narrow
little EntityBroker world. But I'm not going to sit on the side-lines when you spew falsities like "that's impossible" or "no one would ever use it". My posts are not meant to convince you, but to convince others that you are wrong. Deal with it.
:: your design is broken as the layout functionality hould not never :: ever be part of the persisted classes No, I'm persisiting the Graph layout itself (x-y cooridantes), not just the data classes for whatever the nodes represent. :: Because the persistence
will never ever work with the graph :: nodes, but with objects beneath them. Huh? Sounds like you've assumed no one would want to store a graph object. Would you like me to give you the reasons why you would? :) My god this is tedious thona. You go on such
tangents. I feel like I have to explain everything to you. Are you incapable of assuming I know what I'm talking about?
::I would not waste my time trying to convince you of anything thona. You are narrow- ::minded, and don't want to listen to anything but what you've created in your own narrow ::little EntityBroker world. :: ::But I'm not going to sit on the side-lines when
you spew falsities like "that's impossible" ::or "no one would ever use it". My posts are not meant to convince you, but to convince ::others that you are wrong. Good attidude. Sounds like George W Bush is one of your relatives. Which, then, makes you propably
- what was it? "narrow minded". I do listen. Even to you. I just evaluate what you say. And then - take it for what it is worth. ::No, I'm persisiting the Graph layout itself (x-y cooridantes), not just the data classes for ::whatever the nodes represent.
"The Graph layout itself" is naturally part of - well - some persistable objects (maybe the business objects with the other data, this depends but is normally a very bad design). ::Huh? Sounds like you've assumed no one would want to store a graph object.
Would you ::like me to give you the reasons why you would? I never said so. Read again. ::My god this is tedious thona. It really is. Trying to understand your example IS tendious. ::You go on such tangents. I feel like I have to explain everything to you.
Well, would you care to explain them right ONCE, thihngs would be clearer. ::Are you incapable of assuming I know what I'm talking about? No, I am totally capable of assuming your level of knowledge given from what you say. Sadly, the result is not as good
as your think it is. And as a result, I put this filter on ehatever else you say.
thona - do you not sell products and services?? you have the attention of programmers interested in O/R mappers and you are rude to them??? no other industry has this type of direct contact with potential customers, you should take advantage of it. you may
be the most skilled in the world on O/R mappers, but you have alot to learn about business.
Maybe :-) But this IS a topic that is discussed all over the place. This is like walking into a candy shop and asking them whether they know what candy is. Every 2nd thread on this board is around business objects :-) And I doubt he is interest in an O/R mapper
that would handle all this stuff automatically for him :-) Not yet. But you are right - I should be alittle more sensitive.
Well, worse than our Entityroker 2003.0 - and this is last year's version. * Performance sucks big time (they "target" 40% SLOWER than datasets - not good). * Not an option for most of our customers (as in: SQL Server only, and they need more). * No base class,
not bytecode manipulation - which some people here will find nice. Interesting (and indiscutable imho) is the price being paid: the programmer of a CLASS has to determine which references are loaded with it and which are lazy loaded. This is idiotic the USER
of a class has to determine this, as he only knows whether he will touch the subclasses. I can give you an exmaple: invoice, invoicedetails. layzy load or "span" (preloaded)? Depends on the use. Printing invoices: I need the details. Giving an overview (open
invoices for customer, totaly only), I can normally work without ever touching the details. Same object. * No caching. * I THINK (opinion - did not find updated information on this) no inheritance. * They have a designer. Pretty basic from the look (our's
is way more complicated from all the entry fields etc.), but this is IMHO more a sign of primitivity (as in: without configurable cache there is no need to configure one) * No vision. Ok, this is "open", but it is my feeling. It looks like some people thought
"well, lets do objects", and then they put someone who has never done it in charge - and he went out and took datasets. There is a lack or "enterprise readiness". ObjectSpaces requires a local database connection, you have to remote the objets if you wan multi
tiered, but there is no optimisation for this. Half baked. The same "level of architectural vision" that gave us the controls you drop onto WinForms. Makes me shudder. It looks like a 1.0 product. Frankly, and this is just my opionon, please, I would somehow
be ashamed to publish something like this. it is not bad as a 1.0 - but: (a) MS had a preview out earlier than our full blown development started, (b) our team is smalle than theirs, (c) they will in a year when they are finished not be as good as we are NOW.
I was really afraid they would get this one right, but IMHO they have not. Now, how could they do better? Simple: looking at the other offers. I mean, cmon, there ARE reasonable O/R mappers out there which you could go hunting to for the feature list. Now,
there is a difference in positioning - you should be aware of this one, as it explains a lot of limitations. When working with ObjectSpaces, they dont see it as a full O/R mapper. They see it as a "layer of objects on top of ADO.NET". This means they dont
do a lot of things that ADO.NET does, and they put this responsibility on the user. Now COM+ integration (as ADO.NET datasets), no cache, no plans for a remotable layer an an object server. If you ask me (and this again is only my opinion) this is a half baked
approach. OO and business objects are NOT ADO.NET datasets - the rules are different. Been there, tried. Was too limiting. These limits show in ObjectSpaces and make it something a lot of people will like, but everyone with some sense for features in the product
will shudder. And then, again, the hammers: SQL Server only, no caching, no remotable architecture (not remoting - anything remotable)
I was at the PDC and attended the ObjectSpaces talk. Yes it does have some disappointments like you point out. The greatest one is SQL Server only. But that is the same limitation your product and many others have as well. I know you are adding Oracle support
right now so that is good. I don't know why anyone other than MS does not plan for multi-database support to begin with. The performance thing was another one. The 40% slower target was mentioned. Right now they say they are twice as slow as ADO.Net. Some
corrections to what you said: They do support inheritance in single or multi-table form. I believe they mentioned a stream reader so I don't know if they are dataset based. I can't speak to the caching or remotable architecture. As for caching you could always
keep the objects around. I suppose what you mean is that they do not support the idea of single object instance. So if I do an OQuery to get some objects I can end up with duplicates in memory. I'm not sure if that is the case but they did not mention that
they make sure not to have duplicates and given the architecture of the system I suspect they do not support object uniqueness. You say it looks half baked and from a pure O/R mapper perspective I think this may be true to some extent. However, I expected
that whatever MS did with it, it would be a middle ground comprimise to fit some customers. They will have some features where O/R mappers tend to fall short like a reporting capability. Yes it feels like a 1.0 because it is. In the alpha/beta timeframe they
are giving more time to get customer feedback to help shape things up for release. In the end I don't think MS will beat out the other O/R mappers out there. It will be used by some as it will be part of the framework/tools provided by MS. I have yet to see
an O/R mapper that fits all needs. I just don't think that is possible. There are just needs it can't meet that is much easier to do with something like SQL. That is one of the biggest problems O/R mappers have in gaining acceptance. If I can't use it for
all my data needs and I still have to go to SQL for some things why should I even bother with the mapper. Just wrap the SQL in custom objects. Yes it means boring SQL code but some would prefer that to having to develop to multiple access/storage methods.
I think by supporting some mechanisim to get to SQL from the mapper may be helpful. Either through things like a view based object or stored procedure access. Oh well I still have hope, - Eric McVicker
::The greatest one is SQL Server only. But that is the same limitation your product and many ::others have as well. We dont. We work with MS Access since the first release. ::They do support inheritance in single or multi-table form. Ah, ok. ::I believe they
mentioned a stream reader so I don't know if they are dataset based. Last time I checked they are. ::I can't speak to the caching or remotable architecture. This is obvious by the rest of the paragarph. You miss the cache idea. The cache idea is that between
transactions, the system may decide NOT (!) to go to the database but to return data from the cache. This can significantly improove performance. Significantly. Not under all circumstances, but it can really improove them sometimes. If they dont provide uniquing
(same object pointer within the context of one transaction) then the are garbage. Hint: they DO provide it. Remoting means simply to run the objects on an object server. Talk about security. ::They will have some features where O/R mappers tend to fall short
like a reporting ::capability. I dont find info on this anywhere. Info, please :-) I doubt they will ahve anything - a single simple feature - in their PRODUCT that we do not have when they come out. ::Yes it feels like a 1.0 because it is. In the alpha/beta
timeframe they are giving more time ::to get customer feedback to help shape things up for release. And this is what I would be ashamed of, if I would be the developer. See, MS is not really doing anything new here. O/R mappers are around proapbly longer than
the professional career of the people writing ObjectSpace. There is no single sane reason to come up with a half baked product. They could just open a browser and get a list of features that make a good and robust persistence layer. They had a preview out.
It was half baked, but had good promidse. Now, more than a year later, they are STILL half baked. They go the way MS has prooven regularly. hey provide a framework that is not good. May sound brutal, but MS has a long history of making things wrong when it
comes to the architecture of data access in their tools. So far, all the support for RAD has not been too promising, as long as they are for data. See, all the nice stuff they do in whidbey is basically stuff I will gladly just ignore. An ObjectSpaces falls
into this line :-( ::I think by supporting some mechanisim to get to SQL from the mapper may be helpful. What for? Open a database connection and hammer away your SQL yourself. There is nothing in an O/R mapper saying that you have to use it for every statement
you put out.
Hi all, I've read the article posted to ASP.NET about Matisse. It's interesting enough, but all the features presentend can actually be "emulated"/offered by an O/R Mapper. The problem today is that there is no consistent support by vendors to ODMG OQL, so
whatever O/R Mapper, O/R Database, etc you use you get stuck with it. As for ObjectSpace, bah! I was hoping Microsoft would support OO/Custom Business Entities on ADO.NET from the start, that would be something new. Now this thing about ObjectSpaces. Obviously
Microsoft lacks a vision on this subject, or it does not want us to know. At the moment they seam to lack a vision for Enterprise Software too (There is not J2EE Countetrt part!), as the whitepapers presented in MSDN about system architecture, data access
are too juvenile to say the least, including ORM etc etc (but this is all done on purpose). I guess the solution to all these problems is a question of time for Microsoft to catch up, but nevertheless it is annoying to be told what to do only to find out that
you have little support to do things right and fast (fast is not enough). Nuno
Coming in on the tail end, I've used Java persistance layers for a long time and finding some annoyances with datasets etc, I am considering the Value Object [aka Transfer Object] design pattern for my dot net development. Read this article: http://java.sun.com/blueprints/patterns/TransferObject.html
You'll quickly find the Type Dataset mimics this pattern. The value objects can be descendents of serializable base classes to allow for remoting. The actual data access classes manage the storage and retrievel of data for the VO to the database. I took a
cursory look at the LLBLgen tool and it appears it generates this type of code. Anyone see this differently than I am seeing it?
A couple of things I would like to comment on: ::I believe they mentioned a stream reader so I don't know if they are dataset based. >Last time I checked they are. They are not. In 2001 they were, just for expediency because they wanted to get a tech preview
out. I like what they have done for 1.0. They have an ObjectSet which is conceptually equivalent to a DataSet (but not based on dataset) for disconnected access and an ObjectReader which is equivalent to a DataReader for connected access. You can bypass ObjectSpaces
and go right to the ObjectEngine to get a collection of objects that you do not want to track changes (removing overhead of ObjectContext). This should make performance closer to a dataset.
ObjectEngine.getobjectreader >If they dont provide uniquing (same object pointer within the context of one transaction) then the are garbage. Hint: they DO provide it. If what you are talking about is an IdentityMap, they do have it but I don't know how
they are using it. >Remoting means simply to run the objects on an object server. Talk about security. I think they will have support for remoting eventually, they have something called a
ValueRecord for passing around the state of an object. The security issues and all the other issues that surround that architecture is exactly why I think ObjectSpaces will (and should) only provide support for the object server scenario but should not
prescribe a specific way of doing it. ObjectSpaces is infrastructure services. The remote interface layer itself is an application layer built on top of the domain. Two different layers of your architecture. Someone else working at a higher level like Microsoft
Business Framework can prescribe a specific way of doing this if they want. That's why objectspaces needs to be as open and transparent as possible (POCO's). A more prescriptive architecture can be built on top of it. ::They will have some features where O/R
mappers tend to fall short like a reporting ::capability. >I dont find info on this anywhere. Info, pleaseI doubt they will ahve anything - a single simple feature - in their PRODUCT that we do not have when they come out. Luca mentioned in his presentation
that they might work on a reporting/querying language to support the cases where ORM falls short, like querying and grouping for reports. Overall, I think they want to reduce (eliminate?) the times when you have to bypass Objectspaces and go straight to SQL
server, which would also be their motivation for supporting sp's in the future. I know I am opening a can of worms with you Thomas. Fire away!!!
::I know I am opening a can of worms with you Thomas. Fire away!!! Oh, you are not :-) I am just not able to say too much here because MS is watching these forums :-) Just let me say that we have an Investement in the EntityBroker (as MS has in ObjectSpaces)
and that I see the way they are integrating ObjectSpaces into the .NET framework as something that I think may not be so wise. (any vendor selling an O/R mapper can happily get in touch with me by email do discuss details - we MAY have something to discuss
here)
I evaluated EntityBroker only briefly but could not succumb to its overcomplicated view of the database from the code level. After looking at LLBGen and quickly determining that the app definately took the wrong course in what it does, I decided to write my
own. What I set out to do was reverse engineer an existing database and create a data access strategy that worked well in the environment [web] and was low maintenance. What I wanted to be able to do was, whenever a change to the database occurs, press a button,
regenerate the data access tier. Also, I wanted the program to be able to generate any kind of code, be it SQL, ValueObject, or data access classes. Thus I use XSL to transform the schema that it generates from the database. The product is free, source code
included, it works, its extensible, and you can learn quite a bit from using it. It's DBInspector and can be had at http://www.webpit.com
I would recon that every developer that has time to spare would like to write their own ORM. However, this is no simple matter. You can take all the examples you want from any number of current ORM's but this will not get you the knowledge and wisdom to understand
what a solid ORM should offer and provide. I'm sure even Thona - with his 8+ years of ORM experience - at one time or another during development feels like he does not have the knowledge or wisdom to advance it any further. So what to do? Open source projects
are too over-cramped and not flexible enough? How can you get people together to really sit down and engineer a solid ORM from the bottom up that is flexible and realistic in the performance impact it offers? ObjectSpaces: I think Microsoft is just getting
on the wagon and trying to toss a few programmers at it to see what they come up with. This is sort of like every minor initiative this company does. Maybe they will realize if they put forth a solid effort it could really crush all competition, but then everyone
- even you Thona - would be suing them because they are monopolizing your industry. So how far can they go without crushing the competition? If anyone would like to create another, yes another, open source project that is just starting out that is not based
on any other ORM products but open theory and desired features please let me know. Some code I thought up which would make persistance seem simple:
// assembly based, but could be config based [assembly: SqlStorageAdapter(Name="MyAdapter", ConnectionString="Server=(local);Database=Northwind;Trusted_Connection=yes;")] [TableMapping("Categories")] public class Category { [ColumnMapping("CategoryID",
SqlDbType.Int, IsPrimaryKey=true)] public int ID; [ColumnMapping("CategoryName", SqlDbType.NVarChar, 15)] public string Name; [ColumnMapping("Description", SqlDbType.NText, IsNullable=true)] public string Description; } // some code that uses this stuff StorageAdaper
storage = ObjectEngine.GetAdapter("MyAdaper"); StorageContext context = storage.CreateContext(); Category category; category = (Category)context.CreateObject(typeof(Category)); category.Name = "Workstations"; category.Description = "Workstations are for engineers
and developers"; category = (Category)context.CreateObject(typeof(Category)); category.Name = "Servers"; category.Description = "Servers are not for anyone other than operations"; category = (Category)context.GetObject(typeof(Category), ObjectQualifier("Name",
Operand.Equals, "Workstations")); // should get the in-memory object that we first created category.Picture = FileUtil.ReadImage(@"c:\workstations.png"); // delete with object reference category = (Category)context.GetObjects(typeof(Category), ObjectQualifier("Name",
Operand.Equals, "Servers")); context.DeleteObject(category) // delete with qualifier context.DeleteObject(typeof(Category), ObjectQualifier("Name", Operand.Equals, "Servers")); context.SaveChanges(); // changes should be made in order like this: category("Workstations")
should be inserted // and the picture value should be what it was because it was changed before saving // the category ("Servers") does not exist because it was deleted and was only in-memory
Forgive the syntax it was hand coded in the post so the syntax may be off but if you get my drift ... i have all sorts of examples like this on what i want the ORM i end up using to support ...
::SO, is that EntityBroker your using or what? it is not, but his syntax is close enough to the EntityBroker 2003 system of doing things. There are subtile (and not so subtile) differences, though :-)
No it is not EntityBroker, though I have tried several commercial and open source ORM solutions. It is based on code I want to be able to write. Basically, to get my specs I write some code that would make my life easier. Then I build the specs around the code.
I have been thinking about this for quite some time now, about the specs, and I've come to the conclusion that I need soemthing VERY flexible in its data storage. This is because I have to support several different types of data sources: Sql Server, Informix,
Oracle, IDMS, MSMQ, XML, etc... I also need to support odd database designs (ones done previously to ORM solutions being avaialbe.) So I would be able to do things like have an object map to several tables or potentially several tables on several different
data sources. So I would actually switch the code above around a bit. ObjectContext context = new ObjectContext(); Category category = (Category)context.CreateObject(typeof(Category));
I want to hide the data storage adapters that transform bits and chunks of an object into the data that the data source can use. Real world uses? Something as simple as our project request and tracking system combined with our (i.t. only) financial planning
system. Our project request system can sometimes contain a appropriation request. So you would have the object path "Project.AppropriationRequest". Well the Project is part of the PRAT system and the appropriation request is part of the fianancial planning
system. So we have a need to embed an object from another system into our system. Or maybe I am the same programmer that did both and I'm working on a combination site that still uses the orignal data sources but is going to a single code base. Did I mention
our PRAT system is Sql Server and the FP system is informix? Not combined with numerous definition (XML) files for configuration of the FP system (its not entirely based on the database - bad mistake during the original design but it works) and the new integration
with Active Directory I now have 4 different data sources I'm working with. So, my User object is also getting quite complex. It has information from both systems as well as pulling information from AD. (AD is more up to date and we want to at least pull the
most recent information of a user.) So things like Formal Name, Phone Extension, email address, etc are coming from AD, while other non-critical up to date information like last logon, last modified, etc are in the database. Did I mention I don't want to write
a bit of SQL for most of the objects but for complex things I may consider a stored procedure because it will bring me a little less complexity and a little more speed? So I now have along side table mappings and column mappings, now stored procedure mappings
... :) So most normal ORMs won't cut it as you can see. So I've been playing with my object model for the combined system and trying to write physical code on how I would like the ORM solution i buy or build to work into my object model. Ok... wife's a callin...
thoughts?
Dang, my world is so simple compared to yours ;) Even in my own program, where I created my own persistance layer, I find myself challenged and limited... I resist at all levels to embed sql commands or objects anywhere in my code [outside of the data access
layer]. This is due to my desire to seperate the tiers and offer some portability. But it comes at the cost of flexibility. In my old asp days i'd just whip out an sql statement inline with the rest of the code to get the data i wanted. But the way I'm doing
it now is sooo much better :) I like the syntax, but I think its going to cause a lot of runtime overhead.
Let me just say, I am no entirely pro-ORM... As we are migrating from our old mainframe to .NET programs sometimes performance is far too important to let an ORM do its thing in a generic way or to use a DataSet. All ORM's bring a small overhead in performance
but the idea I have is to keep it at a minimum. You would have your entity map that would contain all the information you need to create objects and such. Then you have your storage adapter that uses the entity map to build the appropriate SQL and then create
objects. One idea I had was to take the base class and emit a new class that inherits from the entity object and overrides all the properties or fields and handles all the ORM stuff like checking is dirty, doing lazy loading, etc ... it would appear as the
simple object Category but it would actually be the instance of the new class the ORM emitted. Now to the topic of the thread, it depends what Robust is. What's your performance goals? Rico Mariani has some good ways to plan your performance goals. I'm sure
there are still projects out there that can't make use of ORM solutions because their performance goals are higher than the ORM would allow. But for the average company that is building say an internal expense reporting system it may be enough because you
are only projecting around 200-500 users per week which is quite small. So the ORM performance impact has to fit within the performance goals of the application or it might as well be thrown out. A windows forms application may be able to use an ORM because
the impact is only based on a single user... assume the retrieval and updating of data is within the performance goals of the application. The ORM should really act as the data access layer. You would build your business objects and the ORM would build your
data access layer. Then you build your business services while utilizing the ORM as your data access layer. This cuts out an entire step. Now if only we could get business services automation through rule definitions we would be closer to never having to program
again!
wow this has been a very informative debate... i'm gonna be looking into EntityBroker now. My only concern is the sample code... anytime I deal with an object, i'll have to write in upwards of 12 lines of code? Take the standard "Invoices" / "InvoiceDetails"
object model, which I also wonder, since "InvoiceDetails" actually should have a reference or mapping to a "Product", how is this sometimes needed info brought into the fold? or, to even abstract the 12 lines of code, build a wrapper with a static method?
Ug, all the sudden I've got many layers between the object reference that I have and the datastore... and from a debugging standpoint to proof-of-concept type of projects, looks like a lot of time investment... just some thoughts and i welcome comments :-)
----
E.Newton
ASP.Net/C# Solutions Developer and Consultant
Ensoft Software
http://www.ensoft-software.com/
eric@ensoft-software.com.cc (Remove the CC)
I actually implimented this to an extent and I have used this in my application and it as worked for Access, MySQL, and MS SQL. So don't listen to the Na-Sayers. But I had to readjust my thinking so that I could use an abstract DAL anywhere in my application
and have it clean up after it self when it was done so there was minimal connection time and memory usage. Take a look at what I have done at the following address. http://cvs.sourceforge.net/viewcvs.py/omniportal/OmniPortal/Engine/Kernel/Data/ specifically
take a look at: Provider.cs ProviderFactory.cs ProviderSectionHandler.cs this is how I use it in my program DataSet ds; using (ProviderFactory pf = new ProviderFactory()) { IDbDataAdapter adapter = pf.CreateDataAdapter(@" select * from MyTable "); ds
= new DataSet(); adapter.Fill(ds); } // work with DataSet hereyou can also use stored procedures DataSet ds; using (ProviderFactory pf = new ProviderFactory()) { IDbDataAdapter adapter = pf.CreateDataAdapter("MyStoredProcedure"); adapter.SelectCommand.CommandType
= CommandType.StoredProcedure; adapter.SelectCommand.Parameters.Add(pf.CreateParameter("@myParam", DbType.String, "x")); ds = new DataSet(); adapter.Fill(ds); } // work with DataSet hereIf you have any suggestions for my code on the site or you just
want to chat about how you can impliment this you can e-mail me at my website address listed above or my SF e-mail or just reply here.
None
0 Points
61 Posts
The Design of a Robust Persistence Layer for Relational Databases
Oct 24, 2003 10:59 AM|thwarg|LINK
Member
20 Points
830 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 24, 2003 11:03 AM|m7|LINK
None
0 Points
156 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 24, 2003 01:21 PM|dfoderick|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 24, 2003 03:14 PM|thona|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 24, 2003 03:54 PM|SoulOfReality|LINK
None
0 Points
61 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 24, 2003 04:17 PM|thwarg|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 25, 2003 02:46 AM|thona|LINK
None
0 Points
156 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 25, 2003 02:51 AM|dfoderick|LINK
None
0 Points
349 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 25, 2003 07:39 AM|nbplopes|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 25, 2003 12:07 PM|SoulOfReality|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 25, 2003 01:25 PM|thona|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 25, 2003 06:03 PM|SoulOfReality|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 26, 2003 03:54 AM|thona|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 26, 2003 10:45 AM|SoulOfReality|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 26, 2003 11:20 AM|thona|LINK
None
0 Points
349 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 26, 2003 02:23 PM|nbplopes|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 26, 2003 04:28 PM|SoulOfReality|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 02:52 AM|thona|LINK
None
0 Points
349 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 07:54 AM|nbplopes|LINK
None
0 Points
349 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 08:01 AM|nbplopes|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 11:45 AM|SoulOfReality|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 12:32 PM|thona|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 12:59 PM|SoulOfReality|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 03:06 PM|thona|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 03:26 PM|SoulOfReality|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 03:30 PM|thona|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 03:30 PM|SoulOfReality|LINK
None
0 Points
154 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 03:51 PM|SoulOfReality|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 27, 2003 04:03 PM|thona|LINK
None
0 Points
120 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 28, 2003 10:46 AM|phishstick40|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 28, 2003 11:22 AM|thona|LINK
None
0 Points
13 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 31, 2003 02:43 PM|watchcaptain|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Oct 31, 2003 05:00 PM|thona|LINK
None
0 Points
376 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Nov 01, 2003 02:43 AM|JOAC|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Nov 01, 2003 03:13 AM|thona|LINK
None
0 Points
349 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Nov 01, 2003 01:22 PM|nbplopes|LINK
None
0 Points
45 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Nov 27, 2003 09:08 PM|WebpitSoftware|LINK
None
0 Points
156 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Nov 28, 2003 01:53 PM|dfoderick|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Nov 28, 2003 02:56 PM|thona|LINK
None
0 Points
45 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Dec 19, 2003 10:22 AM|WebpitSoftware|LINK
Member
30 Points
212 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Dec 19, 2003 04:42 PM|adweigert|LINK
// assembly based, but could be config based [assembly: SqlStorageAdapter(Name="MyAdapter", ConnectionString="Server=(local);Database=Northwind;Trusted_Connection=yes;")] [TableMapping("Categories")] public class Category { [ColumnMapping("CategoryID", SqlDbType.Int, IsPrimaryKey=true)] public int ID; [ColumnMapping("CategoryName", SqlDbType.NVarChar, 15)] public string Name; [ColumnMapping("Description", SqlDbType.NText, IsNullable=true)] public string Description; } // some code that uses this stuff StorageAdaper storage = ObjectEngine.GetAdapter("MyAdaper"); StorageContext context = storage.CreateContext(); Category category; category = (Category)context.CreateObject(typeof(Category)); category.Name = "Workstations"; category.Description = "Workstations are for engineers and developers"; category = (Category)context.CreateObject(typeof(Category)); category.Name = "Servers"; category.Description = "Servers are not for anyone other than operations"; category = (Category)context.GetObject(typeof(Category), ObjectQualifier("Name", Operand.Equals, "Workstations")); // should get the in-memory object that we first created category.Picture = FileUtil.ReadImage(@"c:\workstations.png"); // delete with object reference category = (Category)context.GetObjects(typeof(Category), ObjectQualifier("Name", Operand.Equals, "Servers")); context.DeleteObject(category) // delete with qualifier context.DeleteObject(typeof(Category), ObjectQualifier("Name", Operand.Equals, "Servers")); context.SaveChanges(); // changes should be made in order like this: category("Workstations") should be inserted // and the picture value should be what it was because it was changed before saving // the category ("Servers") does not exist because it was deleted and was only in-memoryForgive the syntax it was hand coded in the post so the syntax may be off but if you get my drift ... i have all sorts of examples like this on what i want the ORM i end up using to support ...None
0 Points
45 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Dec 19, 2003 08:26 PM|WebpitSoftware|LINK
Member
20 Points
2877 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Dec 20, 2003 04:03 AM|thona|LINK
Member
30 Points
212 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Dec 20, 2003 08:16 AM|adweigert|LINK
ObjectContext context = new ObjectContext(); Category category = (Category)context.CreateObject(typeof(Category));I want to hide the data storage adapters that transform bits and chunks of an object into the data that the data source can use. Real world uses? Something as simple as our project request and tracking system combined with our (i.t. only) financial planning system. Our project request system can sometimes contain a appropriation request. So you would have the object path "Project.AppropriationRequest". Well the Project is part of the PRAT system and the appropriation request is part of the fianancial planning system. So we have a need to embed an object from another system into our system. Or maybe I am the same programmer that did both and I'm working on a combination site that still uses the orignal data sources but is going to a single code base. Did I mention our PRAT system is Sql Server and the FP system is informix? Not combined with numerous definition (XML) files for configuration of the FP system (its not entirely based on the database - bad mistake during the original design but it works) and the new integration with Active Directory I now have 4 different data sources I'm working with. So, my User object is also getting quite complex. It has information from both systems as well as pulling information from AD. (AD is more up to date and we want to at least pull the most recent information of a user.) So things like Formal Name, Phone Extension, email address, etc are coming from AD, while other non-critical up to date information like last logon, last modified, etc are in the database. Did I mention I don't want to write a bit of SQL for most of the objects but for complex things I may consider a stored procedure because it will bring me a little less complexity and a little more speed? So I now have along side table mappings and column mappings, now stored procedure mappings ... :) So most normal ORMs won't cut it as you can see. So I've been playing with my object model for the combined system and trying to write physical code on how I would like the ORM solution i buy or build to work into my object model. Ok... wife's a callin... thoughts?None
0 Points
45 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Dec 20, 2003 12:25 PM|WebpitSoftware|LINK
Member
30 Points
212 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Dec 20, 2003 08:38 PM|adweigert|LINK
None
0 Points
107 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Dec 29, 2003 09:38 AM|ericy3kok|LINK
E.Newton
ASP.Net/C# Solutions Developer and Consultant
Ensoft Software
http://www.ensoft-software.com/
eric@ensoft-software.com.cc (Remove the CC)
Participant
792 Points
2233 Posts
Re: The Design of a Robust Persistence Layer for Relational Databases
Dec 31, 2003 02:01 PM|nberardi|LINK
DataSet ds; using (ProviderFactory pf = new ProviderFactory()) { IDbDataAdapter adapter = pf.CreateDataAdapter(@" select * from MyTable "); ds = new DataSet(); adapter.Fill(ds); } // work with DataSet hereyou can also use stored proceduresDataSet ds; using (ProviderFactory pf = new ProviderFactory()) { IDbDataAdapter adapter = pf.CreateDataAdapter("MyStoredProcedure"); adapter.SelectCommand.CommandType = CommandType.StoredProcedure; adapter.SelectCommand.Parameters.Add(pf.CreateParameter("@myParam", DbType.String, "x")); ds = new DataSet(); adapter.Fill(ds); } // work with DataSet hereIf you have any suggestions for my code on the site or you just want to chat about how you can impliment this you can e-mail me at my website address listed above or my SF e-mail or just reply here.