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
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.
sometimes i'm using OO des. and sometimes procedural style and everytime i use oop i feel like wasting resources on nothing. say i have a situation where i need to grab some values from datasource, a pool of bannerinfo. For the further work i can declare a banner class and decorators for additional functionality, but why would i do such a hard sequence - i got to grab, instantiate objects, fill them, wrap and so on, rather then just: grab data, run procedural code on data; yeah in many times oop just helps to organize logic and make decisions flexible, but on the other hand it's a waste of time on design (i experience a lot of problems solving simple stuff while putting them into oop style) and obviously a waste of machine resources. i'm kinda stuck in that mindset, im young but i've already seen some projects in oop - i wouldn't say that they're easy-understandable; that idead of oop is pretty charming - organising, making logically, but...
So, would you mind to point out some difference between situations when i should use oop/procedural styles. I'll appriciate any links to additional literature on that topic.Thanks!.
That data you're grabbing has a structure to it, i.e. the order in which the fields show up within each record in the data source. The code you want to run on that data is closely bound to that structure (i.e. the code is not going to apply to other data structures, and if the data structure changes you certainly want to change the code). So it makes sense to keep the data and behaviour together from a "mental information management" point of view, and object are a great way to do this.
What if your program grows, and you want to iterate through bannerinfo in multiple places within the project? Of course you could create a routine available from the whole program which does what you want on the bannerinfo, and call that from each point where you need it. But what if you then think of other things you want to do with a bannerinfo? Of course you could just create another routine available from the whole program, but it would be completely separate from the first. What if these two routines had some code in common that you could push out to a separate routine, would you create yet another routine available from the whole program, even though it's only used by the other two?
With OOP you'd have a class with two public methods, and one private one for that third routine. Why is this different to having three routines available to the whole program? The answer is clutter. You can create as many additional methods on that class, and it won't add clutter to the parts where you're not using that particular class as they won't be available. If the data structure of bannerinfo changes, you only need to go to one place to make the changes.
Of course there's more, but I hope this helps demonstrate where OOP can be useful. Its all about making it easy to manage. If your specifc problem doesn't care for that because it is a one-off, or will never grow, then there's not necessarily any benefit.
Final note: whether the benefit is worth the effort also depends on other factors such as how comfortable you are with using objects, what you're trying to do with them (inheritance can get murky), and also on the language and syntax itself.
"grab data, run procedural code on data"
I don't see how dealing with data can be easier with procedural. With OOP you can do stuff like
$users = $db->from('users')->where('score',100,'>')->getMany();
Or with an ORM:
$user = $orm->entity('User')->findOne($id);
$user->setPassword('abc123'); // set a new password
$orm->save($user);
About showing the data (also called 'the view' in MVC architecture), I have to agree that decorators can be annoying. But if you use a templating engine, things are easy as they can get. You didn't mention which language you are using, but if you are into PHP you can use Twig
Personally, I feel more comfortable with OOP even in small projects, where you don't even do things like unit-testing. But I think the best of OOP comes when you need maintainability, collaboration, reusability, etc.
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.
Somehow I've got the feeling that many projects become heavily overengineered so every possible change-request can be tackled with the effect that the change-requests that occured are very hard to implement.
Somehow I get that feeling in nearly every project I'm currently working on. It is like everyone is thinking "which cool api, framework, etc. can we add to the project to tackle this and that aspect" without evaluating if it is practical or needed.
Does anyone else feel the same or what's the opinion of the community here?
Yes.
-- MarkusQ
I find that, while some older companies with 'senior' senior management tend to be extremely rigid with how their business code is created, newer companies completely lack a backbone of what software they use to get the job done.
The problem you describe sounds like people are viewing problems at too high a level and want to find a way to solve it in one go. Creating a working toolbox (think standard libraries) would help them out in the long run.
I particularly enjoy the UNIX way of things: Several tiny utilities that do one thing and do it really well.
Definitely - I think people get 'robust and modular' and 'overengineered' mixed up far too often.
I think Dave Winer captured the cyclical nature of this phenomenon well:
The trick in each cycle is to fight
complexity, so the growth can keep
going. But you can't keep it out,
engineers like complexity, not just
because it provides them job security,
also because they really just like it.
But once the stack gets too arcane,
the next generation throws their hands
up and says "We're not going to deal
with that mess."
Guilty as charged. Three levels of abstraction and six config files is just more fun to implement than a simple flow control branch.
Overengineering is a danger in any project, large or small. When writing for code extensibility, there's always a trade-off between writing code that is sufficiently generic and extensible to allow for future development and code that is specific enough to make the task at hand easy.
Every "future hook" has a cost and should be evaluated in the light of that cost, the probability that it will ever be used, and the cost of refactoring later in the game. "More generic" is not always better.
As for using a hot, new framework or API, I think project managers should take a gentle hand in this. With development being such a fast-moving field, hands-on self-training is part of the price of doing business (but obviously should be kept reasonable.)
I've only encountered that with Java people: "Lets use spring!" And hibernate! I found this cool validation package as well! And this one will create XSLT to create XML forms to create the javascript!"
By the time I find all the jars and get them to play nice, there are dozens of classes I have to be familiar with. And then they want to abstract away all those pieces! "We might switch spring out. Or not use hibernate, so we should abstract those away". Add another dozen hacky wrapper classes.
By the time its all done, 50 lines of psuedo code has turned into several thousand lines of making the "cool stuff" work, and about 100 lines of business logic trapped within its hairy, hacky, bug-ridden hell.
I'm guilty of it myself, too, but thats only because I'm bored and have time to kill.
The key thing to keep in mind here is time. A "simple" project that is knocked out of the park on day one by an Excel spreadsheet or a web page can quickly expand in both its audience and scope to become an unsustainable monster.
Under-engineering is a danger, too. The world is full of "practical" people who will mock any efforts that are contrary to their opinion. Nobody remembers the person who disagreed a year later when the "simple" solution can't be sustained.
The trick is to balance the right degree of engineering and be able to adjust when things change.
I've been bitten a few too many times by applications that I've thrown together quickly which have subsequently become "critical" apps. Then I have to almost rewrite the darned thing. I just assume now that it will become critical and so I "write it right" the first time. Saves me time and effort in the long term. So oddly, it's about laziness.
Today's xkcd is the absolute truth:
I find that overengineering is a byproduct of boredom. I believe Jeff and Joel covered this in a podcast, but the idea is that coders who often overengineer may just be in a rut and need a change of pace (Jeff and Joel suggested that they be allowed to do different jobs like QA).
Yes. I think people nowadays think more about how something should be done, and whether "it's the right way ..." and so on, than just picking the simple solution which will equally get the job done. If you're not asked to expand it, then don't think about expanding it.
I think this is a problem, but not as big as it seems and that there are good reasons for it.
The problem is that most projects that are underengineered will die a quick death while the overengineered ones can survive. Thus, when you look at still living project, there is survivorship bias.
And, even if you are a good architect that aims for "just good enough", if in doubt you will use the more flexibe, scalable, ... (i.e., overengineered) solution. Because the failure mode if you do not meet the requirements (whatever they may be) is usually much worse than what happens if you exceed them.
I'm yet to work on any real world problem but I've read enough people blogging about this to assume there is a problem.
Absolutely. But it's not just developers, it's users too. "I want this and that and the other in order to improve communication and increase productivity!".
I'm amazed at how many of these types of projects we've solved by just putting a shared folder on a file server.
As others have said, I've had too many 'small' projects become big ones and the short cuts taken become paint.
There is a place for a quick-and-dirty solution and in trying to follow the YAGNI mantra, I've created simple apps with no engineering.
With that though, you are not going to be able to jump into a million line system and develop the 'well engineered' system without practice on smaller systems.
I've taken to always following the developed architecture of our company in all projects because it helps me to work out solutions in line with the engineering principles we are trying to follow.
What you practice, you perform, so always do your best.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
Definition:
CRUD - Create, Read, Update, Delete; The four basic functions of persistent storage. In the context of this question, specifically related to business applications.
I'll be honest, my goal when I began programming did not include being a lifetime CRUD programmer. Financial data is only so interesting for so long. And to me, that seems like the majority of programming gigs.
I'm still fairly fresh out of school, so any experience is still very beneficial, but eventually I want to move to something "less CRUD like." Currently, I have my eye on some machine control type work. However, I'm just not sure how to go in that direction.
So I want to get a feel for what other developers think about the topic.
Do you enjoy CRUD and why?
What have your experiences in CRUD been like?
How did you move from CRUD to non-CRUD work?
If you've moved, what do you like and hate?
If you've moved, what skills benefited/hastened the transition?
Edit:
I'm approaching CRUD with the attitude that I want to solve problems, not re-create the same form with different fields for a dozen different tables.
I don't think that there's really anyone who enjoys doing CRUD (well at least anyone sane). It's the most tedious part of web programming. My advice is to find or write a framework to automate this for you.
evolutility
django admin panel and django forms
However, if that's the majority of your work, you definitely should consider changing jobs.
Get a different job. Seriously, not all software development is developing business applications. Developing shipping software would make you much happier, I think. Try to find a job at a software company, and write some stuff that's going to ship to customers. Also, if you want to get into some of the low level hardware-style stuff, just start hacking away on some basic microcontrollers so you have at least some background with that.
Develop a framework to make CRUD creation easy in your line of work. Once you have done that, use the free time to improve it in terms of Usability, Security, Performance etc. That should keep your work interesting for a while.
I agree that CRUD's pretty boring. But I don't think it's the fact that it's financial data that makes it so. Perhaps you'd find that financial data a lot more interesting if, for example, it was streaming into a neural net based expert system you'd written to work out how best to invest it?
There's definitely an awful lot more to programming than CRUD. Find an aspect that interests you, and pursue it.
I am curious that no one mention task-based UI and CQRS here.
In fact, to answer your questions :
I don't enjoy CRUD...why ? see the following answers to your question
My experience of CRUD is that's a pain to write CRUD (full stack frameworks are a workaround at best I think), and often a pain for users as well
I move to non-CRUD work when I understand that building software is about giving a powerful tool for users, not a database editor with some business rules
I like to build software less coupled to full stack framework (Symfony2, ASP.NET & cie...), more fully object oriented, but I am more and more annoyed by RDBMS CRUD orientation, and more and more attracted by EventStore (Event Sourcing)
Let's get inspired by task based UI, CQRS and Event Sourcing (search Google, I do not have enough reputation to add more links...) => all together
However, I would like to be less opinionated to finish : there are some points that will not let you get out of CRUD. Some users love CRUD, they feel like in Excel...and also there are probably some applications for which CRUD fulfill all the needs...
CRUD - yes in the end we are storing, reading and updating data. But so what? That is just one part of the equation, at least in my world.
In business, data is essential, but it is the business logic and the decisions made from that data that is important. I have found it very rewarding to take raw data and use it to help business make decisions. We do that with business logic in our code, not to mention the endless ways of presenting that data in the presentation layer.
Yes in the end CRUD is involved, but it is much more than that, no?
Just my opinion.
Having a wide range of experience, my solution is to create my perfect product and start a business around it. I'm facing all sorts of interesting challenges, such as how to stream realtime data from an embedded device to a browser. This stuff gets my programming juices flowing and I have a list of important, fun features to add.
Dream up your perfect product domain, find some people who could benefit and ask them what problems they have. Once you pick up a common theme that interests you (mine was automation and power monitoring) start hacking. Of course for me it helps that my father has run the electronics company Technman for the last 30 years, and wants to create this product with me.
First, have you gone through most of what there is to know about persistent storage? It's worth figuring out how to practically apply database theory, etc. in your current job. Once you've been doing it for a few years and have it all figured out you should definitely think about expanding your horizons. I'd agree with you - unless you're building the DBMS itself - I find that the persistent storage part of the job gets to be fairly boring.
One of the best ways to get a job in a new area is to take a prototype of something relevant to the job to demonstrate at an interview. This is an incredibly powerful statement to make.
Embedded software is really my thing, but the market for this is slowly shrinking in North America and moving to the developing world, and it's a fairly specialized area to get started in.
It seems to me that the application space is still growing. Consider iPhone, J2ME, or Windows Mobile development for example. You can learn to do these on your own with a relatively small investment in equipment.
If you're not already doing this, there's also the web application space. Application server platforms like JBOSS and Glassfish are free and fairly easy to learn. Plus they provide a link back to the CRUD which you already know.
Yes, a lot of business software is CRUD. I used to work on that.
In machine control, part of that can be CRUD too. For example, logging sensor data and reporting it somewhere. Basically CRUD.
But I will admit - in machine control, it's mostly non-CRUD. You would probably enjoy doing something that actually makes an assembly line move, or builds cars, or makes motors spin at a certain speed. I know I do. At a financial institution, it's literally just numbers. Nothing "real" like a motor or a car.
Just about every program is going to have to create, read, update and delete some sort of data. In some systems this presents its' own challenges.
However most of the time reading and writing to databases is fairly easy (which is why they make databases). It is what you do with the data once you have it which is interesting, and generally unique to a business, and keeps you employed.
This article I agree with, basically a lot of programming is boring.
However if you are good and determined enough you will eventually get to do something interesting.
Find or write a way to do the CRUD portions of the applications faster. Do so, tell your manager you are done with your assigned tasks (make sure they ARE done; tested, documented, etc.), and ask what you should do next.
Just take a look to Django and move on to the interesting coding!!!
(Or RoR, or Grails, or whichever suit best to you, but CRUDS shouldn't be still being coded by hand from scratch)
Modern frameworks can do all the crud for you. Checkout the standalone GORM from the GRAILS project.
When I was an undergraduate, I changed my major from Electrical Engineering to Computer Science because I wanted to write video games. Later on, when I started working on business applications for real money, I learned that I simply enjoy solving problems with code.
You may be in the wrong profession.
In this economy, it might be hard for you to just get another job, but that doesn't mean you shouldn't try. Find some type of work you think you would enjoy, go learn it and look for job opportunities. It doesn't hurt to make some phone calls and go on a few interviews even if you think you're unlikely to get the job. Even better, you could figure out a way to start your own company.
Get into web-dev? Seriously the level of basic crud I have to do building web-apps is pretty low, even when there's a DB.
For CRUD of windows FORM based applications developed in c# .net
RocketFramework is the answer