|
Sponsored Links
Resources
.NET Research Library
Get .NET related white papers, case studies and webcasts
|
News
News
News
|
Messages: 28
Messages: 28
Messages: 28
Printer friendly
Printer friendly
Printer friendly
Post reply
Post reply
Post reply
XML
XML
XML
|
 |
TSS.NET asks: What’s in an ORM?
A call to ORMs - Stories about object-relational mappers (ORMs) represent one of the more popular topics on this site. As we plan further coverage, we’d like to ask this architect and developer community which traits are most important when comparing and selecting ORM software tools to use in the world of C# and .NET.
Modeling support, query capabilities, quality of code generation, extensibility, ease of debugging - what matters to you? Are ORMs always - or ever - necessary?
Please respond using the 'Post Reply' button.
|
|
|
Message #227000
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Invention is the mother of necessity
I never would have thought of ORM as a necessity until I'd used it. Now I'll never go back. Why write SQL for simple CRUD operations - ever? (And don't tell me about security - unless you mean job security)
As far as features go, the biggest issue by far for me is community support. How many people use the product and how well supported is it? Beyond that, some features I love are:
inheritance support
data projections
dynamic queries
extensible IDE and templating
pre-loading object graphs and/or lazy loading
|
|
|
Message #227004
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
An O/R mapper is an entity / domain model management system.
So, an O/R mapper should be able to manage the entity / domain object for you, from start to finish, or offer features to make it VERY easy for you to plug-in management code (e.g. validation) yourself.
A long list of features can be compiled, but basicly it comes down to that. Mats Helander described it perfectly here:
http://www.matshelander.com/wordpress/?p=30
Persistence of objects is just a small part of modern O/R mapper frameworks. Validation, support for all kinds of databinding scenario's in different UI frameworks, projections of sets onto new sets, in-memory filtering/sorting, concurrency control without limits, transparent distributed application support, etc. etc. These and many more are the features a modern O/R mapper framework should provide.
Though first of all, people should open up themselves to the thinking in entities, instead of thinking in tables and sql queries. As soon as a person starts thinking in entities, an O/R mapper makes sense and the place of an entity in the modern OOP code makes sense. Though it's a necessary transition. I wrote an article about that some time ago:
http://weblogs.asp.net/fbouma/archive/2004/10/09/240225.aspx
It's from 2004, but the point it tries to make is still true.
|
|
|
Message #227016
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Invention is the mother of necessity
I've worked in a lot of different teams on .NET projects. It is very difficult to make people understand the necessity of ORM. In .NET 1.1 and .NET 2.0 DataSets are used most of the time. And until .NET 3.5 (DLINQ) we won't have any product from Microsoft doing the ORM.
So we have to rely on other products commercial or open-source. I've used an open-source ORM, NHibernate, for a very large project at a customer. Yes I have to say, you need to understand the way it works. We have had some difficulties using aggregations, but in the next NHibernate release new features will exist for this. Standard CRUD is very nice, also the Criteria API is very powerful to build Objectoriented queries. Besides al this, I like the way we can seperate the concerns. We don't have to dirten the domain model with mapping logic or database logic. Those things are all seperated.
If you have the choice, I would go for NHibernate.
Yours,
Mark Monster
|
|
|
Message #227020
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Good ORM is an absolute necessity
An ORM to me is the foundation of every project I do. For me, the data model reigns supreme. The fundamental artifact of the requirements gathering process is the data model, and I mean a true physical database model, not some abstraction. Everything we do as engineers we do to flip a bit or store some data, therefore, the underlying data model has to be correct. Knowing this, we use the database schema itself since it’s a wealth of highly accurate information that can be used to generate the bulk of most applications. And when the data model is modified the C# or VB.NET code can be regenerated in seconds. Fundamental to ORM is code generation, not just because the meta-data represents a very large percentage of the requirements but because it creates uniform, defect free code saving man months on any project right out of the box.
The experts will tell you that ORM is far more than this and use phrases like “impedance mismatch” and come up with very complex API’s trying to overcome the supposed shortcomings of the relational model, however, I have never bought into this argument.
I look at it from this perspective. How can I provide the best product in the least amount of time for my client, and above all, turn over a highly maintainable and understandable solution? It simple, pick the right ORM tools that build on top of a very flexible, highly intuitive API and focuses on the main things. The old model of business objects that contain data objects is long dead. Coding should be fun, and can be, there are tools that can accomplish far more than most folks realize.
Mike Griffin
Persistence Layer and Business Objects for Microsoft .NET 2.0
http://www.entityspaces.net
|
|
|
Message #227021
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: Invention is the mother of necessity
I've worked in a lot of different teams on .NET projects. It is very difficult to make people understand the necessity of ORM. In .NET 1.1 and .NET 2.0 DataSets are used most of the time. And until .NET 3.5 (DLINQ) we won't have any product from Microsoft doing the ORM.
Mark, you're absolutely correct. I needed some convincing in the beginning too (to move away from DataSets), and the fact that Microsoft doesn't have a mapper available yet seems to be slowing down the adoption of ORM. Clearly they are moving in that direction though. Unfortunately their technology will be behind what other more mature products have to offer, but it will at least lend a vote of confidence to those reluctant to jump into ORM for the first time.
|
|
|
Message #227024
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TSS.NET asks: What’s in an ORM?
If an application is being developed around domain model objects then providing relational persistence for them using an O/R mapper can definitely boost developer productivity tremendously. A good ORM can shorten (50% to 80%) and simplify the data access code by eliminating the need to write, debug, and maintain endless lines of complex SQL/ADO.NET/JDBC code.
However, I believe that a focused solution to the main problem of impedance mismatch between object-oriented and relational worlds would provide the best results. If an O/R mapper gets stretched out to perform a lot of other ancillary things (for example, different kinds of UI data bindings, dirty object tracking, in memory filtering, etc.), it looses its simplicity and effectiveness.
Once the scope of any framework becomes too large then
a) it starts biting too deep into an application architecture making the framework harder to use,
b) it looses its flexibility and suppleness in terms of its own functional evolution, and worst of all,
c) it may not do the original job in the most efficient way.
It is like turning a pure and simple screwdriver into a fancy Swiss knife – you get neither a very effective screwdriver nor a very useful pair of scissors.
I have written a white paper on the KISS (Keep It Simple and Straightforward) Principles for OR-Mapping products describing the above and related ideas.
-- Damodar Periwal
Software Tree, Inc.
Simplify Data Integration
|
|
|
Message #227022
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Pragmatic for small web apps
For the non-enterprise area it may seem odd to use ORM's, but I have recently started using LLBLGenPro for small .NET 2.0 app development and it's essential so far.
What I looked for with ORM's was:
1-Affordability
2-Ease of implementation
3-Support/Community behind it
4-Documentation
5-Adoption of it or Case examples of the ORM being used in the industry.
I'm leaving out technical criteria such as scalability, framework/pattern extensibility etc... because these are not issues for me with the apps I work on. I develop very small scale apps with a focus on UI.
My current ORM is allowing me to spend 80% of my time on UI and business requirements, and 20% on the lower level code. Also, prototyping is much easier since you can create various versions based on different DB's schema with littler work.
So in a nutshell, I just want a framework that doesn't make me think too much about coding at the lower level anymore.... I just want to focus on the UI and DB schema that makes it possible. Another way of looking at it is that I want the ORM to take care of all work that would typically be "outsourced"... leaving us with the higher level business requirements level coding to do.
|
|
|
Message #227058
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TSS.NET asks: What’s in an ORM?
I'm going to go against the trend : I don't like ORM that much (Object-Relational Mappers). Don't get me wrong : a precisely defined data access layer is a must. But for me, mapping relational tables to objects is NOT a data access layer, because your data access layer should look like your business, not like your physical data model.
SQL is a very good language to manipulate data because it describes what you want to do ; the way you do it is the job of the database. With ORM, you lose this expressiveness (if this word exists in english !), and, in my opinion, you don't get closer to having a data access layer that is useful for your business.
Hence, I make data access layers with methods reflecting the business at hand, not reflecting the relational model I created, and I use SQL underneath (parameterized queries or stored procedures).
My conclusion : for me, ORM (defined as mapping the relational model to objects) is... a waste of time.
|
|
|
Message #227070
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TSS.NET asks: What’s in an ORM?
You're half-right IMHO. Most people try to use their Domain Model in all the layers in their application. This may be correct in many UCs. But there are Use cases in which you have to create a specific model for them; one which doesn't have the complexity of your full Domain Model and is expressive enough to accurately describe and carry all the information needed in that Use Case.
If you hide enough the implementation details of the Use Case business services, you can publish a contract with your tiny "business use-case-oriented" model, and later implement it using an ORM + Full Domain Model,SQL and SPs + DataSets,or even WebService calls + WebService's own model. It's just that it's easier for most OO developers to work with an OO domain model than with a relational database model, and it's also *much* more portable... but if you preffer SPs... your choice :)
|
|
|
Message #227129
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TSS.NET asks: What’s in an ORM?
SQL is a very good language to manipulate data because it describes what you want to do ; the way you do it is the job of the database. With ORM, you lose this expressiveness (if this word exists in english !), and, in my opinion, you don't get closer to having a data access layer that is useful for your business.
My conclusion : for me, ORM (defined as mapping the relational model to objects) is... a waste of time.
I think you're missing one of the very (most) important reasons for using an ORM. It abstracts your data layer.
Using your methodology (building custom stored procedures and SQL), if you need to swap out SQLServer for MySQL, you are most-likely in for a very painful and frustrating experience. For example, MySql expects dates to be passed in as 'yyyy-mm-dd' and Access wants them to look like '#mm/dd/yyyy#'. A good ORM layer will handle this conversion seemlessly.
This can, on occasion, be a limitation because the framework can only be as functional as the least-common denominator of databases it supports, but the tradeoff is well-worth it in many cases.
|
|
|
Message #227133
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TSS.NET asks: What’s in an ORM?
Well, I'm very aware of the differences between SQL dialects, since I work with MySQL, Oracle, SQL Server and PostgreSQL ; some differences can be handled by JDBC or ADO.NET provider using parameterized queries, like the one you pointed out. Of course, there are differences that have to be handled by hand.
But we haven't talked about performance yet ; with a lot of configuration, you can optimize your ORM with lazy loading, but its soooooooo much easier when you know exactly which requests are made on your database and you can optimize the query. In a lot of cases, to get correct performance, you have to get down to the SQL level, choosing joins, creating indexes, etc.
Thus, I guess it's a tradeof between complete database independency and performance. In my experience, it's much, much easier to tweak your SQL than to optimize an ORM, thus I choose SQL-based data access layers. As Lorenzo said, maybe it's a matter of taste too...
One more point : SQL is much easier to learn than learning how to make good use of OO. You can learn the basics of SQL in three days and be operational. It's absolutely impossible with OO.
By the way, I'm looking forward to D-LINQ ; as I said, I think SQL expresses perfectly what you want to do, thus having an "esperanto SQL" available in .NET is a very appealing to me. Since 99% of SQL optimization comes from using adequate joins and indexes, the lost of vendor specific optimizations, like hints in Oracle, will be mitigated in most cases, and you get database independence. Looking forward to it !
|
|
|
Message #227134
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
A Good ORM is an absolute necessity
Mike you are absolutely right.
But for me the ORM in the .NET market should not make the mistake to concentrate on Data Access Layer functionality only.
The mapped objects should be seen as Business Object and the mapper should add a lot of freedom to these objects. Espacially in the .NET market everybody is thinking about rapid development. There are nice things like data binding and data transport in a multi-tier application, something MS supports with their typed data set approach.
The last customer I did visit said: "Hey, I only have a small team and I am able to produce nice little apps with access. I want to have the same development speed for my new c# development also." That is one of my big goals, to bring productivity back to the developers.
Jan Blessenohl
The ORM
http://www.vanatec.com
|
|
|
Message #227155
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
And I agree with your comments. I never use the term DAL, the EntitySpaces objects are Business Objects. The concept of a DAL died out a decade ago for me. Our EntitySpaces Business Objects will run against Microsoft SQL, Oracle, MySQL, Access and VistaDB and I mean "the same exact physical binaries without recompiling". Our massive NUnit test suite does just exactly that against a very large hierarchcial database. Want to swap databases? Well then merely change the connection string in the config and you're off and running.
So the concept of a data layer is dead, we generate and work with highly intuitive Business Objects. You'll never see an ADO.NET data provider in our code, yet you are not cut off from any of the low level ADO.NET logic.
Mike Griffin
http://www.entityspaces.net
|
|
|
Message #227160
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
And I agree with your comments. I never use the term DAL, the EntitySpaces objects are Business Objects. The concept of a DAL died out a decade ago for me. Our EntitySpaces Business Objects will run against Microsoft SQL, Oracle, MySQL, Access and VistaDB and I mean "the same exact physical binaries without recompiling". Our massive NUnit test suite does just exactly that against a very large hierarchcial database. Want to swap databases? Well then merely change the connection string in the config and you're off and running.
So the concept of a data layer is dead, we generate and work with highly intuitive Business Objects. You'll never see an ADO.NET data provider in our code, yet you are not cut off from any of the low level ADO.NET logic.
Mike Griffin
http://www.entityspaces.net
A data layer is dead? Being a commercial ORM vendor I understand that statement... but even if using *ANY* ORM, or manually mapped pure ADO.NET code... a DAL gives you independence on the persistence technology at a very tiny price. It provides separation of concerns and vendor API independence in your business code... but hey, not with your ORM, which requires your entities to inherit from a given base class :) (http://www.entityspaces.net/portal/Products/EntitySpacesArchitecture/tabid/139/Default.aspx) ... in theserverside.com we would call it vendor lock-in.
|
|
|
Message #227162
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
And I agree with your comments. I never use the term DAL, the EntitySpaces objects are Business Objects. The concept of a DAL died out a decade ago for me. Our EntitySpaces Business Objects will run against Microsoft SQL, Oracle, MySQL, Access and VistaDB and I mean "the same exact physical binaries without recompiling". Our massive NUnit test suite does just exactly that against a very large hierarchcial database. Want to swap databases? Well then merely change the connection string in the config and you're off and running.
So the concept of a data layer is dead, we generate and work with highly intuitive Business Objects. You'll never see an ADO.NET data provider in our code, yet you are not cut off from any of the low level ADO.NET logic.
Mike Griffin
http://www.entityspaces.net
A data layer is dead? Being a commercial ORM vendor I understand that statement... but even if using *ANY* ORM, or manually mapped pure ADO.NET code... a DAL gives you independence on the persistence technology at a very tiny price. It provides separation of concerns and vendor API independence in your business code... but hey, not with your ORM, which requires your entities to inherit from a given base class :)
ONLY if you use DDD repositories all over the place and some form of specification so you can specify everywhere in your own code which entities to consume.
The modern O/R mapper isn't just persistence, it's entity management. On Java, it might be different, but on .NET, business objects / entity objects need to be able to bind to gui elements, be (xml) serializable etc. because .NET requires them to be.
Don't get me wrong, entity classes shouldn't contain persistence logic per se (we support both: persistence logic inside entities OR persistence logic outside the entities) though it's IMHO limiting to say that you want your own code clean from the o/r mapper related code, because then you also don't benefit from the fact that the o/r mapper offers more services than just persistence.
May I ask, do you also wrap every form logic in an abstract layer so you can swap out the widget library you're using (e.g. swap the infragistics grid for devexpress's ? ) IF you want to? Or is that 'something different' ?
Anyway, POCO oriented frameworks need some kind of weaving of their own code into the code anyway. Be it post-compile time assembly weaving or runtime dyn. proxy subclassing. Both have downsides you simply ignore for now, but which aren't that simple to ignore in a lot of cases. For example, the dyn. proxy approach, for example used in nhibernate, requires you to use factories to create entities.
Now, how is that NOT making your code rely on the o/r mapper of choice? ;)
Frans Bouma
Lead developer of LLBLGen Pro
http://www.llblgen.com
|
|
|
Message #227167
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
I'm not sure if that was meant for me or not? In fact, I'm not quite sure what your point is. Are you asking me how EntitySpaces is able to switch databases without recompiling? If so here is the answer:
The connection is driven by the config file (we have configless support as well). It looks like this basically.
<EntitySpaces>
<connectionInfo default="SQL">
<connections>
<add name="SQL"
providerMetadataKey="esDefault"
sqlAccessType="DynamicSQL"
provider="EntitySpaces.SqlClientProvider"
providerClass="DataProvider"
connectionString="User ID=sa;Password="
databaseVersion="2005" />
<add name="Oracle"
whatever ... />
</connections>
</connectionInfo default="SQL">
</EntitySpaces>
and in the config you set the default connection to say "SQL" the moniker, you can have a dozen connections, you can tell it to use stored procs or 100% dynamic sql, whether to use our built in esTransactionScope or the MSFT TransactionScope, what provider, ie, Sql, Oracle and so on.
We do not use factories for entities. We just simlpy create business entities like so:
Employees emp = new Employees();
emp.AddNew();
emp.LastName = "Bouma";
emp.FirstName = "Frans";
emp.Save();
That's it, now, I could either change the default connection to Oracle and that code above would work unchanged against Oracle, or I could leave my defautl as SQL and override it at runtime like this:
Employees emp = new Employees();
emp.AddNew();
emp.es.Connection.Name = "Oracle";
emp.LastName = "Bouma";
emp.FirstName = "Frans";
emp.Save();
In fact, we can even read the Employee from SQL and commit it to Oracle using the exact same object in memory this way.
The EntitySpaces data provider is loading via reflection only one time for the life of the application, then it's all .NET normal calls, no reflection at all, no xml mappings files either. It's extremely elegant, we have a massive Nunit test suite that runs on all 5 of our supported databases, we run the same binary against them all.
So you can swap databases, or decide to use local vs distributed transactions, change between stored procs or dynamic sql all via the config file or ala-cart at runtime.
|
|
|
Message #227173
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
So... do you think that the business objects / domain objects /entities / whatever you call them need to know they're being "binded" to a GUI??? That's mixing some layers I guess...
Imagine I couple my business code with GUI binding code... What if I want to expose my business code as a remote interface? what can I do with all that GUI code then?
Springframework.net for example allows GUI binding without coupling with business code...
Oh, and the Infragistics/devxpress example does not apply... or just applies when you allow these components to pollute your business layer, which shouldn't ever be the case, as all these are GUI components and shouldn't have anything to see with business code... just like persistence engines (Or entity management libraries... as you like to say).
The "implementation details" that most ORMs out there use (proxies, bytecode enhancement) instead of forcing you subclass'ing... all these have problems, but allow you a much more loosely-coupled development experience. I just don't want any of my business code to have anything to see with any persistence system, be it NHibernate, ADO.NET or the library you sell.
Separation of concerns and loosely-coupled layers provide much less "magic" gui-managed development experienc, but they also allow a better, more maintainable architecture.
|
|
|
Message #227178
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
Yes, you can bind our Business Entity's directly as they support the correct interface, however, that doesn't mean that there is UI code in the entities at all, our customers do that all the time, the fact that EntitySpaces objects can not only be bound to directly doesn't mean that they know anything about the UI, they don't, nothing reaches up, the UI reaches down through ITypedList and so on. It works the way it should.
Once you have used Code Generation and well honed architecture layers mean nothing, you don't have to agree, but I've been doing that for a very long time now and our customers agree, it's a great way to work. We are not breaking any "architectural" rules at all, in fact, let me see you switch your business layer to another database like we do with EntitySpaces, via a connection string or dynamically at runtime, we haven't corrupted architecture, quite the opposite, we have done it very elegantly, also, EntitySpaces is extremely fast under the hood as the data is left in a DataTable and the get/sets peek in and out of the datatable. You can serialize our Business Entities in xml or binary, return them directly in web services, and bind to them in runtime and even design time right in your winform, it's a great way to work.
The best part is I could walk into your shop, connect to your database, and have your EntitySpaces architecture done and compiling clean in 10 minutes for all 1000 of your tables, and with a fully hierarhical lazy loaded object model, it's tough to beat. Most folks spend months doing what we do in 20 minutes, and it's fully debugged.
So for those that say ORM is no good, well, take it from us that know, you're just never seen it done well.
|
|
|
Message #227179
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
Excuse the typo's (where's the embarrasment emoticon) ...
|
|
|
Message #227187
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
So... do you think that the business objects / domain objects /entities / whatever you call them need to know they're being "binded" to a GUI??? That's mixing some layers I guess...
Sure, but there's no other way. In .NET, if you have a master-detail grid setup, and you bind a collection of Customers to the top grid and to the bottom grid and say to the bottom grid "Use the Orders member" (it's a setting of every grid), you'll have master-detail out of the box. However, if the Orders collection doesn't support ITypedList or IBindingList, you'll have a hard time when you remove a row from the orders grid, or a customer without orders -> no columns in the grid.
If you want versioning in your entity for grid editing (so you can press ESC to roll back to previous versions, or when you added a new entity and press ESC you want to remove it), you have to implement IEditableObject on the entity class.
If you bind a property of an entity object to a textbox's Text property, and you change the value of the property of the entity object, you won't see the textbox change unless you implement a notification interface AND raise an event.
In .NET we don't use controllers and viewers, the mechanism is different. Do we all like it? It makes things easier for the developer who sets up the databinding. It makes things complicated for the business object builders. Though once written, it works OK.
THough this all makes POCO frameworks rather limited. You will end up with POCO classes which contain code which is already there in the base classes of most o/r mappers, so it's up to you: write it yourself or use what's available.
The real deal with POCO is that you can write your code in your own files. In .NET you can of course, in partial classes or in classes derived from the base class offered by the o/r mapper vendor.
Imagine I couple my business code with GUI binding code... What if I want to expose my business code as a remote interface? what can I do with all that GUI code then?
You don't use it. It's there IF you bind it to a UI. If you don't, you don't use it. See it as a capability of the business object to be ABLE to operate in any environment: does the consumer wants to use it in a UI environment? Done. Does the consumer wants to use it in a distributed environment? Done. etc. The consumer just expects to be able to use the business object, why otherwise worry about this plumbing? It's already build in, use it.
Springframework.net for example allows GUI binding without coupling with business code...
Sure, through dyn. proxy which requires you to use factories, the object isn't remotable and you have to virtualize the properties/methods.
Oh, and the Infragistics/devxpress example does not apply... or just applies when you allow these components to pollute your business layer, which shouldn't ever be the case, as all these are GUI components and shouldn't have anything to see with business code... just like persistence engines (Or entity management libraries... as you like to say).
It was an example about 'creating abstractions for the sake of being able to swap out X for Y'. Of course you'll say the grid example doesn't apply, though re-read what I said, it does apply: simply because that too is an element in your complete application which creates a vendor lockin. Of course, you'll now say that the UI layer isnt really your application, but that's just hogwash, it belongs to your application as much as the rest of the code.
The "implementation details" that most ORMs out there use (proxies, bytecode enhancement) instead of forcing you subclass'ing... all these have problems, but allow you a much more loosely-coupled development experience.
You can't use bytecode enhancements in .NET at runtime, you have to use that at compile time.
Personally I agree that in theory people should separate the concerns, and if possible weave them in at whatever point they might see fit. In practise that not always works and .NET isn't setup to be the most perfect environment for this, to begin with the fact that not every property/method is virtual as in Java, so you have to butcher your code anyway to be able to get a proxy.
I just don't want any of my business code to have anything to see with any persistence system, be it NHibernate, ADO.NET or the library you sell.
Great motto, but I haven't seen a reason for this. It's the same braindead discussion they still have in the DDD group over at Yahoo groups: should an entity use a repository or not. Same thing. One half says:of course! otherwise you'll get aenemic entities which is an antipattern, others say NO, of course not, don't pollute your BO's with knowledge about repositories.
It's funny to watch these discussions, simply because the nay-sayers have a point in theory, but in practise they cheat as well and will use repository code in their entities simply because they have to.
Separation of concerns and loosely-coupled layers provide much less "magic" gui-managed development experienc, but they also allow a better, more maintainable architecture.
Great in theory, and believe me or not, by using a base class which has all this plumbing, you effectively DO this. If you don't, you have to write it yourself, sooner or later.
Or write your code in an unnatural way with spring containers and dyn. proxies everywhere. I'm not sure if that tradeoff is worth it, as using a single base class offers the same thing. So, your business object derives from SomeBaseClass... oh, suddenly everything falls apart, right? No, not at all. Because your code is still in a file, in a class where it's contained, not fragmented.
Besides, you really should come with more arguments why what you say is really the way to go, because when you try to achieve what you preach, which is great in theory and to some extend I fully agree, you will have to make sacrifices no matter what. You ignore these as 'umimportant' but I don't think they're that unimportant.
|
|
|
Message #227188
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
Ooops, I too should have used the preview button... WHy can't you edit your own posts here?
Anyway, I had to close a blockquote somewhere, and I forgot...
It should have been:
I just don't want any of my business code to have anything to see with any persistence system, be it NHibernate, ADO.NET or the library you sell.
Great motto, but I haven't seen a reason for this. It's the same braindead discussion they still have in the DDD group over at Yahoo groups: should an entity use a repository or not. Same thing. One half says:of course! otherwise you'll get aenemic entities which is an antipattern, others say NO, of course not, don't pollute your BO's with knowledge about repositories.
It's funny to watch these discussions, simply because the nay-sayers have a point in theory, but in practise they cheat as well and will use repository code in their entities simply because they have to.
Separation of concerns and loosely-coupled layers provide much less "magic" gui-managed development experienc, but they also allow a better, more maintainable architecture.
Great in theory, and believe me or not, by using a base class which has all this plumbing, you effectively DO this. If you don't, you have to write it yourself, sooner or later.
Or write your code in an unnatural way with spring containers and dyn. proxies everywhere. I'm not sure if that tradeoff is worth it, as using a single base class offers the same thing. So, your business object derives from SomeBaseClass... oh, suddenly everything falls apart, right? No, not at all. Because your code is still in a file, in a class where it's contained, not fragmented.
Besides, you really should come with more arguments why what you say is really the way to go, because when you try to achieve what you preach, which is great in theory and to some extend I fully agree, you will have to make sacrifices no matter what. You ignore these as 'umimportant' but I don't think they're that unimportant.
Frans Bouma
http://www.llblgen.com
|
|
|
Message #227191
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: A Good ORM is an absolute necessity
Yes, you can bind our Business Entity's directly as they support the correct interface, however, that doesn't mean that there is UI code in the entities at all, our customers do that all the time, the fact that EntitySpaces objects can not only be bound to directly doesn't mean that they know anything about the UI, they don't, nothing reaches up, the UI reaches down through ITypedList and so on. It works the way it should.
Once you have used Code Generation and well honed architecture layers mean nothing, you don't have to agree, but I've been doing that for a very long time now and our customers agree, it's a great way to work. We are not breaking any "architectural" rules at all, in fact, let me see you switch your business layer to another database like we do with EntitySpaces, via a connection string or dynamically at runtime, we haven't corrupted architecture, quite the opposite, we have done it very elegantly, also, EntitySpaces is extremely fast under the hood as the data is left in a DataTable and the get/sets peek in and out of the datatable. You can serialize our Business Entities in xml or binary, return them directly in web services, and bind to them in runtime and even design time right in your winform, it's a great way to work.
The best part is I could walk into your shop, connect to your database, and have your EntitySpaces architecture done and compiling clean in 10 minutes for all 1000 of your tables, and with a fully hierarhical lazy loaded object model, it's tough to beat. Most folks spend months doing what we do in 20 minutes, and it's fully debugged.
So for those that say ORM is no good, well, take it from us that know, you're just never seen it done well.
I do the same with NHibernate and a custom Java-based code generation tool. And know what? I also generate basic business services interfaces, Daos, Dao interfaces, Basic business services which use Daos, ASP.NET pages for listings (from NHibernate-mapped views, not tables), ASP.NET pages for editing Nhibernate-mapped tables (entities)...
In less than 20 minutes :)
|
|
|
Message #227231
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
There is an alternative!
I strongly believe that seperation between domain og model is best achieved by a data access layer designed for the specific application. Implementation of such a layer should be replaceable!
Implementation of such a layer could be done using an ORM. That oftens makes good sense. However, there is an alternative. Why not choose a database that match your model? Why not choose an ODBMS?
I think there is too much focus on ORM tools. Go take a look at alternatives such as http://db4o.com. If you still feel you need a ORM, fine. If you don't. Congratulations, you saved yourself a lot of work and probably some money too.
|
|
|
Message #227234
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: There is an alternative!
I strongly believe that seperation between domain og model is best achieved by a data access layer designed for the specific application. Implementation of such a layer should be replaceable!
Implementation of such a layer could be done using an ORM. That oftens makes good sense. However, there is an alternative. Why not choose a database that match your model? Why not choose an ODBMS?
I think there is too much focus on ORM tools. Go take a look at alternatives such as http://db4o.com. If you still feel you need a ORM, fine. If you don't. Congratulations, you saved yourself a lot of work and probably some money too.
I strongly agree with you :) but the database, when created from scratch in a RDBMS, is a good place to describe the meta-data in your model. If you follow some conventions (a-la Ruby on Rails and all that stuff/puff) you can achieve great simplifications and much more rapid development without compromising good architecture design.
The current problem with ODBMS systems is just that basic business intelligence or even reporting is quite difficult with them. Anyway I think db4o is one of the greatests pieces of software out there for OLTP-only systems.
|
|
|
Message #227477
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
An ORM Should at least do ORM
The essential part of an O/R Mapper is to map objects to tables. Funnily enough, in many, many mappers only a relatively small part of the code base is related to this ability.
In my blog post that Frans linked to earlier (http://www.matshelander.com/wordpress/?p=30) I suggest that we start talking about Domain Model Management (DMM) for all the other stuff that a mapper often does but that really doesn't have anything to do with O/R Mapping as such.
To begin with, an O/R Mapper is usually relevant when you have a Domain Model (DM) and a relational database. If you have just the database the O/R Mapper isn't motivated. If you have just the Domain Model the same thing applies.
However, it turns out that a lot of what an O/R Mapper offers /is/ relevant even if you have just a Domain Model. These features that are useful regardless of persistence are the ones that fall into the DMM category. They aren't really O/R Mapper features but you'll often find them in O/R Mapping frameworks. Examples include Inverse Management, Dirty Tracking and Data Binding support.
The reason is that an O/R Mapper deals with Domain Models and so has a good view of what functionality is helpful when dealing with DMs in addition to the pure persistence aspects.
However, you could easily imagine a pure DMM framework dealing with these things and complement it with a pure O/R Mapping framework for handling the persistence when needed. IMHO, most of the DMM features are fruitfully approached using AOP techniques. So a DMM framework could simply consist of a bunch of aspects for your favorite AOP framework.
Mats Helander
http://www.puzzleframework.com (The home of NPersist, NAspect, NFactory, NPath and ObjectMapper)
|
|
|
Message #227487
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
Re: TSS.NET asks: What’s in an ORM?
It’s always amazing how much attention ORM draws in the .NET community, given how (relatively) rare use of it still is. Compare this to the Java community, where ORM doesn’t even elicit a yawn anymore and it is common sense to use one of the available frameworks.
Taking a broad view, the following topics regularly pop up when discussing the pros and cons of using ORM and which ORM to select:
1) The dreaded learning curve and debates on ease of use
There’s no doubt that ORMs are quite complex frameworks that require effort to learn. This is where the quality of documentation and samples comes in and that’s why users are well advised to check both before settling on a tool. It also means that active, responsive support is vital for lowering the entry barrier. Related to occasional difficulties in this area is the current lack of common standards in .NET for ORM. This issue at least may be partially resolved by LINQ in the near future, since it will set a standard for query languages. All other aspects of the topic are (and are likely to remain) unstandardised due to their nature: there are many valid approaches.
2) The target platform
There’s no question about it: any ORM has to keep pace with the advances of its development platform, in this case .NET. For example, for .NET users, it is imperative that their ORMs support generics, System.Transactions and databinding mechanisms offered by the platform. Otherwise, projects can end up locked in some outdated framework and cannot move to the new features of the platform. This may be more of a risk when frameworks are only ported from another platform to .NET and the framework’s evolution mainly takes place on that other platform and not on .NET.
3) Intrusion into architecture
An ORM framework is indeed a central, determining factor in any architecture, regardless of how “transparently” it offers persistence services. The more you try to abstract an ORM from your architecture, the more plumbing work you have to do and the more ORM features you lose. The tack of abstracting an ORM so much that you can *easily* exchange it for another is a myth: by the time you have abstracted enough, you will have reduced the whole thing to the common set of features of all possible ORMs, which is almost zero – they hardly have anything fully in common. The challenge is therefore not to abstract it to the point of non-existence, but to become aware of all the implicit architectural decision when using the ORM. Checking whether an ORM supports all the architectural scenarios you are going to need is therefore crucial.
4) Added value as compared to other solutions
There plenty of ORMs out there at the moment, and all of them provide a more or less good solution for persistence. The question is whether or not they have added value and unique selling points as opposed to other, similar products. If Microsoft release their own ORM, this point will become even more important: any third party ORM will definitely have to offer added value over the MS solution by the time LINQ2SQL gets released. In this respect, Genome ORM offers the advantage that any existing code can be migrated to LINQ anytime, without scrapping any of the work done previously. This is obviously something that many users are currently brooding over, as they understandably do not wish to embark on great coding forays if they’ll have to throw all that code out again when LINQ arrives.
5) Flexibility in data retrieval and leveraging the underlying database platform
Many ORMs limit the ways in which data can be queried from the database. I’m firmly of the opinion that aggregates, sub-queries and the like should be first class citizens in an ORM’s query capabilities.
6) Flexibility in mapping between the domain model and the database model
This is not a 1:1 relationship, as concepts of the object oriented world can be translated in different ways to a relational model. The most obvious difference is inheritance, but apart from that, a domain model is still much more expressive than a database model: relationships, arbitrary associations and arbitrary queries can be encapsulated and expressed on a rich domain model (imagine a decimal Customer.GetOrderVolume(int year) method or a Set<Order> Customer.OpenOrders collection property), which in the best case are spread across hard-to-maintain stored procedures in a database-centric implementation approach.
The other important feature of an ORM is to allow adaptation to legacy database models, which have often existed for a long time in the organisation and cannot be changed (a typical old architectural anti-pattern in enterprise-wide developments is to use a database as interface between independent systems). To support such dinosaurs, an ORM has to be flexible as regards primary key structures (field types and composites), primary key value generation (database or business logic generated) and must take foreign key constraints into account when updating.
7) Performance
This is a topic typically brought up in “ORM: yes or no” discussions rather than comparisons of ORMs, but bear with me. A decent O/RM implementation will allow you to optimise performance in an application with significantly less effort than doing this in a manually written DAL. If you take it to extremes, the abstraction an O/RM provides will have some performance overhead. However, I doubt projects usually go into optimisation so extreme that this overhead would become visible, as optimising means taking shortcuts… i.e. making the code even more unmaintainable. We are talking not only about a one-off cost when developing the project, but also an ongoing cost. Consider this comparison: nobody would implement their web application in an assembler today - for performance reasons. The frameworks we build on top of operating systems (including .NET CLR, ASP.NET etc.) provide good performance while significantly increasing productivity, and ORM is just another piece in this puzzle.
More importantly though, an ORM must scale. We implemented PetShop4 with Genome and compared implementation and performance. Our Genome implementation was 10% slower than the optimised PetShop implemented by Microsoft (although I would call their optimisation extreme within the boundaries provided by ASP.NET). On the other hand, the Genome Petshop only needs half the code and supports more databases than the MS Petshop. So you see, the 10% overhead doesn’t really hurt, especially when taking into account that the scalability of the two implementations is the same. Adding another server costs far less than creating and maintaining the manual DAL of MS Petshop, so it's worth considering this.
So much for my copious comments, I'm just realising that this reply has become rather lengthy. Obviously it's an issue of burning interest for us too :)
Elina Heinonen
Genome - ORM with LINQ support
|
|
|
Message #243572
Post reply
Post reply
Post reply
Go to top
Go to top
Go to top
|
|
GURA adheres fully to the O/RM Mandate
Imagine if you bought a car that had a non-detachable trailer. It would be handy to have on occasions, as you sometimes need to deliver and carry thing here and there. But what about the days when you just want to go to the shops, or visit friends, or a quiet cruise in the countryside. No matter if you used it or not, if you wanted it or not, the trailer would always be there making life easy on occasion and the rest of the time difficult.
This is how many Object Relational Mapping tools have been designed. Proper object oriented design rules would state that as an O/RM is about data access and translation then only the parts dealing with these points should be included in your O/RM. Any additional features should be included in other software that can then be used if only desired. But most O/RM’s are one large program that includes all functionality within it, even if it has nothing to do with data access or translation. The additional functionality is carried along, like the trailer, even if it is required or not.
Car designers do not make cars with non-detachable trailers because it locks the user into a situation where they have no flexibility. Object relational mapping tools should be no different, they should only include the functionality for their specific purpose so as to promote maximum flexibility. Additional functionality should be included in another layer of software.
GURA, the new breed of O/RM, has been designed solely for the purpose of data access and translation. There is no superfluous functionality, it only contains the functionality you require to make high quality, properly designed business applications.
GURA promotes full functionality with many other features that make it unique in the O/RM field.
Read more about GURA
Thank You
Steven Hughes
D2O Pty Ltd
|
|
|
| |
|
| New content on TheServerSide.NETNew content on TheServerSide.NETNew content on TheServerSide.NET |
|
|
Language "mashups" will become more prominent, and developers will become polyglots, one programmer suggests.
SearchWinDevelopment.com offers an introduction to the language, performance, testing and data management improvements in VS 2008.
VBCode.com code snippets cover all aspects of application development, from data binding to security to the user interface.
Get up to date on XAML best practices with a variety of articles, tutorials and webcasts. [SearchWinDevelopment.com]
One team's experience with the VSTS DB edition suggests that it can improve workflow for dev teams. It also enhanced Agile efforts.
(June 24, Article)
Microsoft has begun to include DSL tools in the VSTS kit. A new book by Steve Cook and other VSTS team members helps set the stage.
(June 24, Article)
Cartoon: Be it ever so humble there is no place like your home after you get a Microsoft Home Server .
(June 18, Cartoon)
Microsoft's Thom Robbins says new technology to highlight in NET 3.5 includes AJAX, LINQ for both C# and VB, as well as tooling enhancements intended to ease the task of building WPF, WF and WCF apps.
(June 29, Podcast)
Venkat Subramaniam discusses AJAX bottlenecks, the tenets of Agile development and more. He spoke at the Ajax Experience.
(June 25, Tech Talk)
In the second of a two-part series, Michele Leroux Bustamente discusses design decisions related to the claims-based security model. Read the story and walk through the process for creating a set of claims-based utilities to encapsulate claims authorization at the service tier.
(May 24, Article)
Understanding why the Entity Framework exists and learning where it can fit into your projects can get you prepared for the eventual release early next year.
(May 10, Article)
Resource: This learning guide gives you quick access to useful links on Windows Communication Foundation security information.
(April 24, Article)
TSS.NET's Jack Vaughan spoke recently spoke with Microsoft's Brad Abrams to find out what he is seeing in the field and what the chefs in Redmond are cooking. Along the way he discusses patterns of AJAX frameworks.
(April 11, Article)
In a two-part series, Michele Leroux Bustamente explains how claims-based security is supported by WCF, and how you can implement a claims-based security model for your services.
(March 29, Article)
Windows Workflow Foundation is a new technology that many developers will need to get their heads around. In a brief excerpt adapted from Programming Windows Workflow Foundation: Practical WF Techniques and Examples using XAML and C#, K.Scott Allen considers aspects of workflow definition.
(March 22, Chapter Excerpt)
|
|
