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.
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'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 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.
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.
Do you primarily think of reasons TO implement it, or reasons NOT TO implement it? What are the advantages of each?
This fine Joel Spolsky post basically says:
Make a list of possible features.
Vote to filter out the worst features.
Assign a cost for each feature.
Allot a limited feature budget to each participant.
Find out which features are popular when allocating the budgets.
I usually do a cost benefit analysis. How much is this going to cost to implement (in money or time) and how much is the benefit worth (again money or time).
If the benefits outweigh the costs by enough of a margin, it gets done.
The measure is usually money for paid work, time for personal stuff although there's sometimes a crossover. I won't sacrifice too much quality time with the kids no matter how much money's on the table.
I think first about the stakeholder (the client).
Will that feature help him ? Is it indeed a functional feature that brings value?
Then I think about technical implications and the resulting complexity, in order to evaluate the trade off between implementation cost vs. not having that feature.
Based on those two first elements of reflexions, I can begin to know if I must implement it or not.
I guess there is no clear cut between reasons to or not not implement it.
I think that it is important to consider both pros and cons, with the end result being a cost benefit analysis.
The landscape of that analysis can shift a lot depending on the sort of product the new feature is proposed for. A lot of my work is on big complicated applications that have evolved over time and are core to the business of my customers.
Consequently a lot of analysis of a new feature focuses on why not to implement a feature; I will largely concentrate on risk:
How well architected is the area where the new feature is to be introduced?
What is the level of unit testing already implemented?
Is the new feature being implemented right at the heart of the application?
What happens if we miss something and a bug gets out into the wild, could it bring the system down (either literally or by effectively making the system unfit for its purpose)
At the end of the day, it is the customer's decision on whether or not a new feature is devloped. As professional software developers it is our responsibility to inform them of possible costs that may not be visible to them beyond the bare dollars and time.
The happy flip side is that we also have the responsibility to propose new features that they may not have thought even possible!
A lot of the time we're asked to put in a certain feature. Part of my job is being able to interpret this in the context of users who think they know what to include all the time. Sure, they know what they want, but you can bet someone else wants something slightly different. Its important in my world that we can think one step ahead and deliver more. We're paid to think how the business works and provide for them.
Thus, i come up with the strategy of adding something a bit more powerful, and then also delivering what the user wants as well. Thus, when someone else asks for something, its already there. This can save a lot on costly delivery cycles.
Unfortunately, this is not always available or practical, but if possible, i like to do it. I like to run with the motto that coding should be proactive rather than reactive.
The customer gets to decide on features. If I think of something I run it by the customer. Together we figure out how to get the customer's most important features implemented soonest.
Fantasy decision-making question: Does feature improve product's ability to do what it is particularly suited to do? If yes, implement feature, else don't.
Reality decision-making question: Do we have enough money to justify implementing feature? No? Crap.
It should be the client/customer/stakeholder/consumer that should drive what feature needs to be there. The client can be a real world user (single company or individual you are delivering) or not (a market you are making a product for). But either way, it has to come from an end-user.
We call all our new features "user stories".
What you certainly need to do is to understand why the user wants that feature - what is the problem that the user is trying to solve or advantage it wants to gain. You need to get the 'why' part from the user before you get to 'how'.
Implement a feature if it will help the user complete a certain quicker or complete it with more knowledge. If it will help the user, implement it, if it makes your app look better but doesn't really help the user around the application (just looks good) then don't implement it.
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.
After reading Wolfbyte's answer on Enterprise FizzBuzz I have thought about what constitutes a program as "Enterprise".
What makes an application or a software development process as Enterprise?
EDIT: It seems like there is a lot of negativity around the word Enterprise.
Are there anyone who actually enjoys writing Enterprise-Level applications?
What "enterprise-level" really means is:
Compatibility with architectural schemes and long-term technical plans that overarch anything you or your team will ever do, and thus cannot be changed.
Conforms to governance requirements
Expensive to build and maintain ;)
Has the following qualities:
Maintainability
Scalability
Functionality
Reusablility
Reliability
Understandability
Usability
Modifiability
Testability
Portability
Efficiency
Flexibility
Modularity
Interoperability
As far as "enjoying" writing Enterprise-level apps, it can be difficult to do so because one of the characteristics of an enterprise system is that it's larger than any one person. People usually enjoy their work because they can take ownership of it, but enterprise development isn't really "owned" in that sense, rather it's "produced" through a rigid, complex project path guided by acceptance gates and steering committees and business project owners.
Think about all the things that you, as a programmer, care about in a software product.
Now think about all the things that you, as a user, care about in a software product.
Now forget about all of those things. Enterprise software isn't purchased by users or programmers. Requirements like "intuitive", "fast", or "interoperable" just don't apply.
Instead, they must meet requirements such as, "vendor published big fat whitepaper full of words like 'fast', 'intuitive', and 'interoperable', so when the peons complain that it makes their jobs more difficult we have something to point at while writing 'difficult' into their employee records".
Slow. Hard to use. Expensive. Based on obsolete technology. See the rails plugin "acts_as_enterprisey"
I kid.
Seriously though, it generally refers to things written for use by Fortune-1000 types, where there are large numbers of users and complex business rules.
If you're an ordinary developer, it's anything bigger than what you're working on now.
If you're an architect, it's the stuff you did at the last client.
If you're the CIO, it's all the stuff that "really matters" -- the stuff above baseline, keep-the-lights-on operations.
If you're in sales, it's what you're bidding on.
If it's your product, of course it's enterprise-ready. You just spent a year making it "scalable" so it would grow to support "the enterprise".
If it's open source, of course it can't be enterprise-scale. Nor, for that matter, is your competitor's product.
And, of course, it varies by client. For the $1B per year companies, a few Oracle financial reports was an Enterprise Initiative. For a Fortune 100 company, almost nothing is really "enterprise" because the entire enterprise is so big and globe-spanning that it's hard to comprehend any one thing that actually fits all the nooks and crannies of that conglomerate business.
Usually Enterprise is used in the negative. "Your software/service/product/offering isn't enterprise ready" or "Open source isn't suitable for enterprise computing".
An Enterprise Application usually something that has multiple tiers and runs on many machines and is designed to fulfill the needs of an larger organization. In practice it usually has a database backend, business logic middle tier, and some kind of frontend like a web interface. Likely has performance and high availability requirements, as well as backup, logging, auditing, and authentication.
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