As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
For a new project we are looking at NHibernate. We like it a lot overall, but one thing bothers us: it seems to be very resource consuming. Apparently NHibernate will load all the properties of an object even if you need only one of the properties. More over, it will do the same for the properties of child objects.
So we are weighing the pros and cons of NHibernate. What would you say they are, and if the upsides make up for the downsides?
Disadvantages:
It can take a while to get the hang of editing HBM files (although you could use Castle's ActiveRecord, which does session management, and let's you declare relationships with attributes, which it uses to generate HBM, since NH is underneath AR. Note: you don't have to use the AR pattern with Castle's AR).
It's probably going to run more queries to retrieve a particular graph of data than you would if you wrote it by hand
It's more difficult to make use of the power of the DB engine, since NH treats is like a dumb record store
Oracle support is not as good as other dialects.
Advantages
You can use Linq-to-NH, and use linq style queries against all the supported dialects.
You can use HQL instead of SQL
You can switch DBs venders with a couple lines in a config file
There are tools to generate your schema for you.
Support for versioning of instances
Advantages:
Second Level Caching
Creates the objects representing your data natively
Creates the SQL queries and avoids SQL injection
Lazy loading
Following foreign keys are easier.
DB translation (change the dialect)
The framework is well supported and is opensource
There are lots of tools that work with and generate code/mapping files for Hibernate
Disadvantages:
Can be slower than direct querying
Object initialization is slower than by hand
Initial configuration is a pain
Mapping is checked at runtime and that can be a pain to setup
It depends what you are doing. Hibernate is not the tool for bulk updating.
Here are some things that haven't been mentioned yet (sorry, it's not in pro/con format). These apply to situations where you will be creating a generic framework to do basic entity operations (so you have a reusable NHibernate library that you can use for other projects).
Setting it up is a real pain. Ours is stable now, but we started developing it a year ago.
Consider the type of applications you'll be developing (i.e., web forms or WinForms), because the session model you use in the generic framework may be different; or, you might want to develop a framework where you'd want to be able to plug in your own session management implementation. There are a lot of choices here.
If there is a chance of developing a highly concurrent application using the framework, design the concurrency model right from the start -- it could be very difficult to get it working properly later on.
If you use the NHibernate.Mapping.Attributes library, you don't have to deal with external XML mapping files. All you do is add metadata to your data object classes. This is really handy, intuitive, and easy to maintain.
That's all I've got for now. If I think of anything else, I'll add to my list.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a bunch of C code accessing database (Oracle, DB2 and Sybase) through Embedded SQL : the base code is the same, but with three different precompilers, three sort of executables are built, one for each database/platform.
I works perfectly fine, but we need now migrate to a solution using ODBC access.
The problem is : what tools / api can be used ? A direct way seems to write a custom precompiler (or modify an existent) to wrap all SQL and host variables calls to calls on an ODBC connection.
Can somebody recommend tools for that task or api to keep it simple ?
Or is it a simpler way, another approach ?
Thank you
As is usual for such situations, there are likely no off shelf answers; people's codebases always have a number of surprise in them, and the combination prevents a COTs tool from ever being economical for individual situations.
What you want is a program transformation system (PTS), with a C front end, that can be customized to parse embedded SQL. Such tools can apply source-to-source rewrite rules ("if you see this pattern, then replace it by that pattern") to solve the problem.
These tools require some pretty technical effort to configure. In your case, you'd have to adjust a C front end to handle embedded SQL; that's typically not in C parsers. (How is it that you can process this stuff in its current form?) You'll have trouble with the C preprocessor, because people do abusive things with it that really violate a parsers nested-structures-view of the universe. Then you'll have to write and test the rules.
This effort is a sunk cost to be traded against the effort of doing the work by hand or some more ad hoc scripting (e.g., Perl) that partially does the job leaving you to clean it up. Our experience is that it is not worth the trouble below 100K SLOC, and that you have no chance of manual/ad hoc remediation above 1M SLOC, and in between your mileage will vary.
At these intermediate sizes, you can agonize over the tradeoffs; that costs energy and time, too. Sometimes its just better to bite the bullet and do it any way you can an clean it up.
Our DMS Software Reengineering Toolkit is one of these PTS. It has a customizable C parser and preprocessor, precisely to help deal with these configuration troubles. The other PTSs mentioned in the Wikipedia article, do not, I beleive, have any serious C parser associated with them. (I'm the guy behind DMS).
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've read a blog post called Blogging with Noir, and I was honestly surprised that the author uses java.jdbc instead of libraries like Korma which I found surprising. What are the advantages of writing SQL queries in your code instead of letting tools do it for you?
I guess it is for the usual reasons that you might choose to use an API directly in Clojure rather than use a wrapper:
Existing knowledge: you already know the JDBC well and know that it will get the job done, why spend time learning a new abstraction unless there is a clear advantage?
Uncertainty - does the library have all the features you need? Will it continue to be maintained and implement new features in the future?
Stability - the wrapper may not yet be mature, so you run the risk of your code having to change if breaking changes occur / bugs are discovered.
Completeness - the wrapper may not (yet) encapsulate all of the functionality of the original API that you need
Overhead - sometimes extra layers of abstraction add a performance overhead that you don't need/want
Extra dependency - adds complexity to your build, and conceptual overhead in terms of the number of abstractions you need to keep in your head.
Ultimately it's a trade-off - the above are reasons that you might want to use the underlying API, but there are equally good reasons that you may choose to use the wrapper:
More idiomatic - a wrapper library is likely to give you much cleaner, more elegant code than a Java-based API (particularly if the Java API is imperative/stateful). You have to admit that Korma is pretty elegant!
More composable - Clojure wrappers tend to adopt a functional style, which leads to easy composability with other clojure code / libraries.
New features - often Clojure wrappers add extra functionality that the original API does not posess (for example, look at the data binding functionality added on top of Swing by Seesaw)
Korma IMO isn't nearly ready to be used as a full replacement for SQL. It's definitely handy, but right now a lot of my queries have (raw "...") snippets in them, and for more complicated stuff all the main querying is done inside SQL views which are then selected on via korma.
The main alternative, ClojureQL, doesn't even work with Clojure 1.3+
In short, it's hard to abstract SQL, and Korma - even though it tries to be minimal, meaning you still have to understand SQL pretty well to use it - isn't finished.
I can think about two reasons:
Almost everybody knows SQL, almost nobody knows Korma
This is a guess, because I do not know Korma myself, but raw SQL is sometimes suitable or even necessary if you want to do something specific like features that are only present in a particular database
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
The advantages of ORM are pretty clear. But I noticed that some companies prefer to build their own home made ORM. Why?
There are only two arguments that I can possibly see for ever hand-rolling your ORM (and these have happened to me in the past, which forced me to write my own):
The company refuses to use Open Source software because of liabilities they assume might creep into their application.
The company refuses to spend money on a commercial ORM.
Any other argument (like the quality of Entity Framework is too poor for us to use it) is completely moot. No matter how bad Entity Framework (or whatever other ORM you may be referring to) is, you're not going to come close to the robustness and reliability by hand rolling your own.
As O/R mappers are very complex pieces of software, writing your own which goes beyond the typical datareader wrapper and pre-fab SQL query executor will take a lot of time (think 6+ months full time at least). That's not the biggest problem. The biggest problem is that once you go with your own O/R mapper, you have to maintain it for the rest of the time the application using it is in production. Which can be a long time. Make no mistake, maintaining an O/R mapper yourself is not a simple task: you have to re-invent every trick O/R mapper developers already know about and have solved themselves.
Last but not least: doing this yourself should not be done on a billable contract. After all, you're writing infrastructure code which is already available elsewhere.
I know I'm biased (I wrote LLBLGen Pro), but I also am one of the few people in this industry who has written a full O/R mapper framework and knows what it takes to get a decent one up and running with good performance and a great feature set.
Simply do the math: if it takes 1000$ to get an o/r mapper framework license (or less) and you can get started right away with the application of your customer, how many hours do you get for that 1000$ so you can built the O/R mapper without costing the company any money? And maintain it? No way you can do it for that money.
If you have an in-house database that has evolved to have a bad schema, it can be simpler to write your own ORM layer than try and get an out of the box solution to play nice with it.
In my opinion, ORMs are specialized and purposed to solve typical problems. If you want some more generic solution (e.g. for much more complex queries) or just different functionality you can either modify existing solution (what for various reasons often isn't the best choice) or create your own.
ORMs also limit you by forcing you to use their conventions and accept their limitations.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I would be interested in hearing op opinions from others regarding whether which they would choose (no 'neithers' please ;), and why.
What are the downsides to using fluent? (version dependancy maybe?)
Pros, Cons, Experiences etc.
Fluent NHIbernate sits on top of NHibernate, so its not really a choice between the two. If youre going to use NHibernate, CHOOSE to use Fluent NH on top of it to save yourself vast amounts of effort.
Fluent NHibernate is awesome, I wouldn't use NHibernate without it. You can fluently map all your entities (giving you compile time checking, and automated testing support) instead of having to maintain cumbersome xml files and remember their syntax/DTD.
It can also automatically map your entities based on default and/or your own custom conventions.
Just use it!
I would definitely say go with fluent-nhibernate. Just be aware it may not necessarily be as smooth a ride as you would hope.
Regarding version dependency
I have had a 'reverse' dependency issue when upgrading to a new version of FNH required me to upgrade to a new version of NH (2.0 to 2.1 I think). This was not a major issue for me.
I just recently (this morning) dropped NH 2.1.1 into the FNH 1.0 RTM (this is distributed with 2.1.0) without any dramas (yet).
Edit: Since writing this post FNH has matured substantially to the point where I do not think this is a real issue anymore
Mapping support - some mappings are not yet possible with fluent nhibernate. However, this is NOT a reason to avoid FNH as hybrid fluent-xml mappings allow you to fallback on traditional xml in the event of fluent being unable to map it (although this is only on per-class granularity). Examples of mappings:
Cannot yet map fields - http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/a7787927dafd23a/84ce2616946a18d7
Cannot map some times of dictionary http://groups.google.com/group/fluent-nhibernate/browse_thread/thread/d38b6c72250cd2fb - actually from what I gather this functionality exists but is not in the mainline yet.
Compound complexity factor. From the sounds of it you will be learning both FNH and NH at the same time. For the majority of fairly simple applications this is fine - infact FNH is often so good that you need to know fairly little about the hbm.xml mappings. But if you want to go do something reasonably complex, it will rarely work the first time round and you are left wondering if it is a PEBKAC, fluent or NH issue. More often than I'd hoped I ended up writing the traditional xml mappings (of course, you are doing this anyway, but it would have been preferable not to expend more effort than necessary fiddling with fluent first).
The advantage of using Fluent NHibernate together with NHibernate is that you get compile time errors if you have messed up your mapping, instead of runtime errors. You also get a much better experience when refactoring your code, since your mappings are kept up to date as you rename properties or whatever, instead of having to remember to manually modify you XML mapping files.
The biggest downside of Fluent NHibernate is that it is still in a quite early phase of its development, and there is quite a big risk of breaking changes as the development of the framework progresses.
Personally I havent really gotten much into fluent nhibernate as I am comfortable with the mapping files. using visual studio to create the mapping files is a breeze and you can set the schema for the xml file which gives you intellisense on the the mapping file. I agree that having compile-time syntax checking is an advantage to using fluent-nhibernate, but I struggle justifing learning the fluent API when I already am familiar with the XML mapping. Perhaps I should just get over my lethergy and learn it already... :-)
Fluent N-Hibernate is really a nice wrapper over NHibernate. To manage mapping in Fluent much better than xml mapping. Development become fast as you get on to Fluent...
Best if you use Entity Developer for creating entity and Database schema.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Let's say you're in an IT shop that allows no ORM tool of any kind. They don't want to buy one, and neither can you use an open source solution.
What would you do? Give up on a real domain model and work table-centric? Craft own DAL?
Strictly speaking your options are:
Don't use a relational database
Don't use an OOP language
Otherwise some kind of ORM solution is inevitable (even if you roll your own, its still a simple ORM layer).
Options:
Roll your own
Quit
Use an open source one anyway without telling them, show them the prototype when it's working well, then ask them to reconsider open source.
Based on your username, I'd say "use LINQ." It's built into .NET and it's not an ORM (strictly speaking).
If you truly cannot use one of the existing ORMs, then I do not advise creating your own. Locally grown ORMs tend to be half-implemented, poorly-designed, wart-ridden beasts that appear to help for the first six months, then gradually become the biggest time-sucks on the project.
You can do without an ORM if you apply patterns like "RowDataGateway" or "TableDataGateway" from Fowler's Patterns of Enterprise Application Architecture.
You'll still end up growing your own isolation layer to separate your domain from the database, but it won't be as expensive to create as rolling your own ORM.
There are three possibilities here:
Your bosses don't understand the benefits of using an ORM.
Your bosses are doing things the way they always have done things and won't consider changing.
Your bosses have valid reasons for not choosing an ORM.
More than likely though, it's a combination of these three things. They probably have valid concerns that could be cured through better understanding of ORMs. My advice is to try selling them on ORMs. Find a particularly nasty piece of code that could be cured by using an ORM and make a prototype that shows how much that code could be simplified. Also, be willing to compromise.
If they're not willing to budge on this, you need to ask yourself if this is really a place you want to work. Not because they won't let you use ORMs (which you could probably live without), but because they won't listen to you. You can't always have your way, but you should have input on the development process.
I'd roll my own DAL, using something along the lines of Generic DAOs to abstract it in such a way that the rest of my code isn't tightly coupled with however I'm getting to the data.
That makes it easy to swap it all over to an ORM if they come around later.
If it's about the company being too cheap to buy one, then write your own, and at the end of the project show them the cost in terms of your time. (I assume they're against free alternatives on principle)
If it's about performance, you might have to check whether they have a point.
If they worry that it adds a layer of complexity which other developers will have to learn, then show some examples of code simplified with the ORM.
If it's because the application is already very "table-centric" you'll also have to think whether adding an ORM will improve things or just add a lot of unnecessary mapping complexity.
(Oh, and read this : http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx )
Craft your own DAL, like we did in the beforetime, the long long ago... 2004.
First off, it's absolutely retarded that you can't even use an open source one.
If you have to roll your own, it's not a huge deal. You can still have domain models just fine. You might have an easier time if you model each record, and then build the domain models to load data from that as an intermediate format.
See what they think about iBatis (http://ibatis.apache.org/) which isn't an ORM but helps you get objects from database queries without inscrutable ORM magic, lots of XML though.
How are they doing things now?
I would roll my own solution, probably using some kind of code generation tool. Tecnically if you translate the results (be it datareaders, tables, recordset or whatever) to your objects you have a small o/r mapper, very lacking but still... It is a matter of definition I guess.
My primary goal would be to avoid repeating CRUD in my code, it takes time, is boring and is a source of defects.
As stated: if a relational database is not required you could always go with some object database. But thoose are far more uncommon and if your boss is against orm:s he is unlikely to go for that.
Ask why ORM's are not allowed, what constitutes as a ORM, and then decide from there 1 of two possibilities:
Deal
No deal ( quit )
If you decide to build our own DAL, Davy Brion has a quite good tutorial for that.
Take a look at the Build Your Own Data Access Layer Series.
"no ORM tool of any kind. They don't
want to buy one, and neither can you
use an open source solution."
No ORM any kind OR just open source/$$$?
There are free versions of great ORM tools:
Telerik Open Access Express: works with Express databases
Web: http://www.telerik.com/products/orm.aspx
Lightspeed Express: limited to eight model classes
Web: http://www.mindscape.co.nz/products/LightSpeed/download.aspx