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.
I already know that ember.js is a more heavy weight approach in contrast to backbone.js. I read a lot of articles about both.
I am asking myself, which framework works easier as frontend for a rails rest backend. For backbone.js I saw different approaches to call a rest backend. For ember it seems that I have to include some more libraries like 'data' or 'resources'. Why are there two libraries for this?
So whats the better choice? There arent a lot of examples to connect the frontend with the backend too. Whats a good working example for a backend rest call to this:
URI: ../restapi/topics
GET
auth credentials: admin/secrect
format: json
Contrary to popular opinion Ember.js isn't a 'more heavy weight approach' to Backbone.js. They're different kinds of tools that target totally different end products. Ember's sweet spot is applications where the user will keep the application open for long periods of time, perhaps all day, and interactions with the application's views or underlying data trigger deep changes in the view hierarchy. Ember is larger than Backbone, but thanks to Expires, Cache-Control this only matters on the the first load. After two days of daily use that extra 30k will be overshadowed by data transfers, sooner if your content involves images.
Backbone is ideal for applications with a small number of states where the view hierarchy remains relatively flat and where the user tends to access the app infrequently or for shorter periods of time. Backbone's code gets to remain short and sweet because it makes the assumption that the data backing the DOM will get thrown away and both items will be memory collected: https://github.com/documentcloud/backbone/issues/231#issuecomment-4452400 Backbone's smaller size also makes it better suited to brief interactions.
The apps people write in both frameworks reflect these uses: Ember.js apps include Square's web dashboard, Zendesk (at least the agent/ticketing interface), and Groupon's scheduler: all applications a user might spend all day working in.
Backbone apps focus more on brief or casual interactions, that are often just small sections of a larger static page: airbnb, Khan Academy, Foursquare's map and lists.
You can use Backbone to make the kinds of applications that Ember targets (e.g. Rdio) by a)
increasing the amount of application code you're responsible for to avoid problems like memory leaks or zombie events (I don't personally recommend this approach) or b) by adding 3rd party libraries like backbone.marionette or Coccyx – there are many of these libraries that all try to provide similar overlapping functionality and you'll probably end up assembling your own custom framework that is bigger and requires more glue code than if you'd just used Ember.
Ultimately the question of "which to use" has two answers.
First, "Which should I use, generally, in my career": Both, just like you'll end up learning any tools specific to work you'll want to do in the future. You'd never ask "Backbone or D3?"; "Backbone or Ember" is an equally silly question.
Second, "Which should I use, specifically, on my next project": Depends on the project. Both will communicate with a Rails server with equal ease. If your next project involves a mix of pages generated by the server with so-called "islands of richness" provided by JavaScript use Backbone. If your next project pushes all the interaction into the browser environment, use Ember.
To give a brief, simplified answer: for a RESTful backend, at the moment, you should use Backbone.
To give a more complex answer: It really depends on what you're doing. As others have said, Ember is designed for different things, and will appeal to a different set of people. My short answer is based on your inclusion of the RESTful requirement.
At the moment, Ember-Data (which seems to be the default persistence mechanism within Ember) is far from production ready. What this means is that it has quite a few bugs and, crucially, doesn't support nested URIs (/posts/2/comments/4556 for example). If REST is your requirement, then you'll have to work around this for the time being if you choose Ember (i.e. you'll either have to hack it in, wait, implement something like Ember-Data from scratch yourself, or use not-very-RESTful URIs). Ember-Data is not strictly part of Ember, so this is entirely possible.
The main differences between the two, aside from size, are basically:
Ember tries to do as much as possible for you, so that you don't have to write as much code. It is very hierarchical and, if your app is also very hierarchical, will likely be a good fit. Because it does so much for you, it can be difficult to figure out where bugs are coming from and to reason why unexpected behaviour is happening (there is a lot of "magic"). If you have an app that fits naturally into the type of app that Ember expects you to be building though, this likely won't be a problem.
Backbone tries to do as little as possible for you so that you can reason about what is going on and build an architecture that fits your app (rather than building an app that fits the architecture of the framework you're using). It's a lot easier to get started with but, unless you're careful, you can end up with a mess very quickly. It doesn't do stuff like computed properties, auto-unbinding events, etc and leaves them up to you, so you will need to implement a lot of stuff yourself (or at least pick libraries that do that for you), although that is rather the whole point.
Update: It appears that, as of recently, Ember does now support nested URIs, so I suppose the question comes down to how much magic you like and whether Ember is a good fit, architecturally, for your app.
I think that your question will soon be blocked :) There are a few contentions between the two frameworks.
Basically Backbone does not do a lot of things, and that's why I love it : you will have to code a lot, but you will code at the right place. Ember does a lot of things, so you'd better watch what it is doing.
Server discussion is one of the few things that Backbone does, and it does a great job with it. So I would start with Backbone and then give a try to Ember if you are not totally satisfied.
You can also listen to this podcast where Jeremy Ashkenas, creator of Backbone, and Yehuda Katz, member of Ember, have a nice discussion
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 was recently working on a Web Service Project and realized my choice of architecture was extremely inefficient.
I wrote this in a very procedural manner with a hint of OOP and standard Exception Handling using Python. Basically, it would procedurally step through the data, validate existence of expected data, validate the data against a regular expression, validate some data against a database, perform some specific logic, check for errors, and then finally return a response. It might be helpful to mention that all data was exchanged using JSON.
I tried to go back through the code, find any duplicated exceptions, and push their handling to the top of the logic chain. This was not as easy to do as I had hoped and actually cost more time. It also made my code more prone to bugs by being less Unit Testable and harder to read.
I've noticed this paradigm of procedural code for handling User Data is very easy to fall in to with Web Development. For example, while handling a Form in PHP one may run a consecutive series of isset() and !empty() methods on the data. My problem with this coding style is that I feel like I'm spending an enormous amount of time coding for Error Events and it's difficult to generalize and re-use code for this particular purpose.
Various frameworks offer great ways around this through the use of Form Classes (e.g. Django). However, I have noticed that while you save time by reducing the duplication of Validation Logic, you will still need to "build" a Form for each expected input. When dealing with Software as a Service, there can be potentially hundreds of API Methods that you must code for. OOP offers a benefit here but there are times where a client may set an odd requirement which removes any efficiency gained.
Web Applications can benefit greatly from following paradigms/architectures such as MVC. In my personal experience, MVC (and the frameworks which use its principles) are not well tailored to this type of problem. I've considered the use of Functional Languages but have yet to give them a try.
Are there any particular languages, architectures/paradigms, conventions, or even example frameworks that are well suited for the development of custom SASS or Web Service Projects?
As someone who does a lot of this work, I would say that part of your problem with OOP and PHP is caused because initially PHP was not an OOP language. OOP was added to the language later on. So when you look at code examples they often can have a procedural feel.
In recent years I've been most happy with either Spring (Java) or WCF (C#). Both these languages are strongly typed OO languages. From a conceptual standpoint this leads to a paradigm that works well for my projects. Here's the overview:
Endpoints (Either REST or WSDL) -- similar to view in MVC
Services -- These feed the endpoints and coordinate DAOs as needed. Organize these around your business logic
Data Access Objects -- convert data into native objects and vice versa. Organize these around your data sources.
Model / API -- Native Objects to support application and automatically provide documentation for your service.
Hope that helps
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 7 years ago.
Improve this question
I found around 8 Strenghts and flaws of using APEX over another program(http://en.wikipedia.org/wiki/Oracle_Application_Express), but i am not sure i quite understand WHEN to use it.
From what i understand, if you want a fast and easy-to-use development tool related to Oracle, Apex is your first choice. While if you need a complex solution, APEX won't fit.
I would like to know you guys opinion on this. In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented. We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates.
Apex is free, and an oracle XE database is free too. Apex is rapid development.
But what you're asking depends on so much more.
From what i understand, if you want a fast and easy-to-use development
tool related to Oracle, Apex is your first choice.
Is an oracle database already being used?
Easy to use dev tool: yes, sure. But as with anything, it depends on whether you have some experience with it, what the specs and expectations are, ...
While if you need a complex solution, APEX won't fit.
Well,... Would a complex solution be so much less complex in another environment? Just how complex are we thinking? In my opinion, you can go pretty far in apex and adapt it to your needs. it might involve creating templates and plugins to set up a framework, but it is doable. An example would be apex projects whom have been completely integrated with ExtJS. Apex is not the answer to everything too, but it's good. If you'd stay within the Oracle stack for more involved/complex, i'd say the next thing is ADF. Personally, i'm not convinced by that one though. It also has its pros and cons (such as: requiring java knowledge. pro for some, con for others...)
In my case, i need to know if i should recommand this product or not for a raquetball club. Since it is not a big company, i believe HTML DB would be the best choice because we want as less manipulations as possible once it's implemented.
How large is this club? How intense will the website be used?
Is there a DB already? Is it Oracle?
Who has DBA knowledge (even basic)?
Who will develop?
If your specs are up to spec, then much fiddling shouldn't be necessary after the launch.
We also don't want the owner of the club to pay a lot of money to get somoeone who can develop updates
Who will host the server? Who will run it? Who will administrate it? Do you plan to go cloud-based?
I'd almost ventured to suggest PHP may be a good alternative if this is a small project. Those developers may be easier to find and less expensive than an apex/oracle developer. But then again, if you're planning to outsource it may be less of an issue. If your oracle instance would be in the cloud somewhere, you'd even be pretty safe i'd believe...
Really, what options are you trying to compare? You're asking about apex, do you have any experience with it?
Honestly, your question is not so much a question as it is an opener to a discussion. Each technology and database will have its pro's and cons, fans and dislikers.
Personally, i really like apex. It has a lot going for it, especially when you're already invested in the Oracle stack. And it is still growing, getting good support, and great releases with lots of new features.
I can't really say how it must be set up a (reliable) service from the ground up: server and database, doesn't matter how small, you'll need some understanding and knowledge for that. If you just wing it and cross your fingers, you'll burn them somewhere down the line. Same with development. But as far as i'm concerned that goes for any other tech. Unless you outsource those aspects of course.
Etc etc. There is much and more to be discussed this way.
I put a downvote there for these reasons: there is much to be discussed, it isn't really much of a question which has a conclusive answer. And it maybe only could fetch a conclusive answer if you put more specifications up there and get people of the concurrent platforms to respond.
Edit
I'd like to react on Daniel's post.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
I'm a developer too, and i don't do server and database administration (corporate environment). Not that i haven't dabbled a bit here and there in my spare time, but i digress.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
So speaking as a PHP developer, would you even recommend PHP to achieve this? Would it be less or just as complex?
I'd also argue about complexity. I've worked on some large forms, which for me by now means there are more than your average amount of items, some dynamic actions, validations, maybe some custom process(es). I've not encountered extremely complex situations and honestly i'd question who created those expectations. Thinking outside the box may be a virtue at times, but that doesn't mean the box is always bad. Complex mechanisms or pages can maybe be broken down into more easily accomplishable parts. An example would be using modal pages to break it up.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms.
I agree about limited programming experience: you'll only create the most basic forms and reports, and having almost no experience i'd think you'd shy away from even option pages in fear of breaking something. Same thing goes for even basic db and server administration: i wouldn't like to rely on such a person when there is no experienced backup (but a very small project as is apperently being described might be acceptable).
I too am only invested in the programming side.
It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
I'd say that the templates make things very flexible and are certainly not hard to use
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Wow. I strongly disagree with this. I've maybe encountered one such thing over the course of a year and tons of forms. Not that i haven't heard of some problems on the OTN forums, but usually they had to do with upgrades.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
It is too bad that there are not that many large, public sites which use apex out there. As far as i'm aware, there are and have been large project involving apex, but those usually are in a corporate environment and thus are never shown off (can't be). I personally believe apex can be pushed a lot further than the basic forms+reports you mention (and i mean basic, because things will usually come down to forms+reports in this context).
Debugging does not have to be a pain though. If you provide enough debug messages and comments in your own code, that will help a great deal. Debugging the page, javascript console, and if needs be an autonomous error logging procedure to be used in your plsql packages,... I'd say there is plenty to help out (and if you're driven to this, you are working on some more complex material, and i assume that you have the knowledge to actually deal with the complexity you've set up).
And interesting point you raise lastly is maintenance though. I'd say a point on which apex should improve a lot is versioning, out of the box. Exports need to be improved so they can be broken up a lot easier.
Wow, look at that wall of text... I could've guessed this would turn out into a discussion.
First I have to say that I am originally a PHP-Developer, and I really like this language and environment. Nevertheless I decided to do an internship this summer, where I am currently working with APEX. Together with another intern I am developing a bigger application, and I hope to give you some useful input. This only covers the development of the application, as I am not really involved in things like database administration and so on (although I have to say that a PHP Webspace with a MySQL Database also isn't to hard to administrate, especially if there are not too many users).
To start we created a few applications, just to get a feeling. Afterwards we started with the easy parts of the application. APEX is really great if you only have to build some reports and forms to edit the entries of the database. It's very fast to create these things with the integrated wizards.
But my experience is that it gets very, very hard to solve tasks which are out of this range. That doesn't mean that you can't get multiple tables in one reports, some joining of tables is also not a big problem, and can be easily achieved. But if your application needs even more than this I cannot recommend APEX, so I totally agree with your rule, that complex applications should be created in another way.
I also think that the slogan with the limited programming experience is only partial true. It is only true if you have only easy applications, as you have already said. I personally also can't stand the mixing between an IDE and "easy to use"-forms. It's also not very easy to create new templates and other things, at least in my opinion it would be much easier with other frameworks.
And maybe even the worst thing: I think that this application is quite buggy. I don't know how many times simple deleting and new creation of a process/page/validation or whatever solved a problem, where you are simply not thinking of this solution.
Summary: I would only use APEX if you have application which REALLY fits it. That means just reports and forms, everything which is more results in pain debugging sessions (as this is also not easy in this environment...) and bad maintenance.
I am posting here as a guest--hopefully, I will create an account. I used O-HTML-DB from its early releases. We built pretty fine apps. I last used it in 2004, having moved to non-development roles.
Since 2007 though, I decided to revisit the tool and found out about APEX. I have since had my own test apps. I disagree with most of what the intern says.
If you have a limited objective (your business need and associated requirements), then your use of APEX will be limited. This is a very robust application, with sophisticated security features (I have been in InfoSec/Cyber since 2009.
Yes, you are correct than claims about APEX not requiring a solid development background are not accurate. You need to have a sound grasp of SQL/PL/SQL, JavaScript. But you c an also take great advantage of OTN, where developers generously share their know-how. When I started with O-HTML-DB, I had never built a DA in a business environment before. I had theoretical SQL skills. I was a Web Developer with a grasp of JavaScrip, training in Java from Learning Tree International (in addition to academics). But I and my colleague (we were two developers) learned a great deal from OTN. We built three Web apps, one of which supported over 6,000 users--just O-HTML-DB!
APEX has taken O-HTML-DB to new dimensions. You do not need to hard-code validations like we did with O-HTML-DB. Of course, you can modify, which requires a sound grasp of SQL/PL/SQL.
Maybe templating is somewhat confusing to many developers, understandably. But as you continue to "play" with APEX, I am sure you'll like it. It can do nearly anything. Only your limited vision will restrict it.
Erick
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 am almost 100% locked in to Django for the projects I have been planning.
The final "myth" I'd like to "dispel" is that Django is "mediocre" at
conveying business-logic.
Direct quote by Peter Shangov:
Whatever your choice of framework your real-life needs will very
quickly outgrow the functionality available in the ecommerce modules
that you started with, and you will end up needing to make non-trivial
changes to them or even rewriting from scratch sooner rather than
later. This is because open source has always been exceptional at
building infrastructure tools (think web servers, templating
languages, databases, cacheing, etc.), but relatively mediocre at
implementing business logic. So what I'd be looking for if I were you
is the library that I'd be happiest to hack on rather than the one
that looks most mature.
"Products" which I am putting Django (with satchmo) up against:
Ruby on Rails (with spree) [Ruby]
Catalyst [Perl]
JadaSite [Java]
KonaKart [Java]
Shopizer [Java]
Could you please alleviate (or confirm) my concerns regarding the
aforementioned quote about Django?
The short answer - of course its bad, because its not a business process management software; it is a framework for web development and getting things done.
The long answer - you need to clarify what you mean by business logic (and "conveying" it). Are you talking about process mapping, workflow management or the execution of the process itself?
I do not see how the other projects you listed "convey" business logic - because they are not business process diagramming or testing or validation packages. They are simply frameworks to do some work. Once the process has been defined and validated (using some external tools), you can then execute that process in your code.
In terms of online shopping - the business "process" as far as the store front is concerned is quite standard and you can easily map it to any of the packages you have listed. You did not mention what kind of store you'll be running or what your fulfillment or delivery processes are, so cannot give you a detailed response if satchmo has those components built-in or would you have to write them from scratch.
The only possible negative when it comes to django is that it doesn't have a mature workflow engine (the two main projects GoFlow and django-workflows are stalled), but this is hardly a criticism against django since it is not a generic web framework. It is designed for a specific application for which a complex multi state workflow engine is not a primary need.
Finally, as far as the quote is concerned - without knowing the context - I can only say that one of the most popular business process mapping software is actually the open source JBoss BPM engine.
I don't doubt that closed-source/proprietary people are great at building infrastructure tools and frameworks too. What they don't do is release them, or let people play with them. They build on them themselves, making money by sticking "business logic" specific to the businesses who give them the money for it.
If you go for a proprietary solution there will doubtless also be some non-trivial changes required, and you'll pay through the nose to the one company that provided you with the (not quite) solution. "Oh, another $4000 to add an extra class of fields to the database? Hmmm. Oh I guess we've already paid you $100,000 and your software is closed source so we can't subcontract it to a tendering process... Here you go..."
Open Source is better at implementing business logic because, when it comes down to it, its people that implement business logic, not frameworks, and open source means more people can work with it.
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 6 years ago.
Improve this question
I'm a .NET web developer for a small organization. We have some skilled developers here, but what we don't have is anyone who's worked for larger, more organized, software shops. We do all right, but I find myself wanting to structure my code better with little place to turn for advice.
It comes to this. At some point someone in our organization decided we were going to use webservices whenever we had to do any data access at all no matter the case. Thus, our hardware architecture is organized so that is the only way we can access our databases. This sounds fine in theory, but the problem is most of our apps turn out like this:
Spaghetti Mess Of Code In The aspx.cs -> Web Service That Does Nothing But Call a Stored Procedure
Beyond that there's not much separation. Whenever I start trying to research better structural practices I wind up reading about things like dependency injections, dirty properties, and class factories, my head starts to swim, and I move on to something else in frustration.
Here's a basic example of my wonderings. So let's say I have to make a page to select employees from a list, edit them, and update the database. Is it better to have the web service return an Employee object on a get, and accept an Employee object on an update? Or is it better to have the Employee object call the webservice to self populate?
In other words: Employee emp = svc.GetEmployee(42); vs Employee emp = new Employee(42);
The second example seems like it would be better organization for updates (update the relevant properties and call emp.Update()), but the problem is what if I need to get a list of Employees? It would be inconsistent to do Employee emp = new Employee(id); for a singular employee, but do svc.GetAllEmployees() for a list.
I feel like I'm rambling a bit so I'm going to cease trying to explain and hope someone understands my confusion. I appreciate any advice that anyone can offer. Thanks!
As with anything, there are a number of different approaches you can take. (So hopefully there will be a number of good and different answers here, because this is definitely an important question.)
One question you should probably ask yourself about your design is "how much logic will need to be shared between applications?" Going with the small GetEmployee example you gave, it sounds like you want to know where to put the models in your domain. Are these models used by multiple applications? Is business logic shared across applications?
If so then you may want your domain models behind the web service. Maybe build up a rich domain behind those services with its data access and external dependencies (remember that dependency injection thing, the best design decisions will need to be in the domain behind the service layer since that's the core of the whole system).
Then, of course, how do you access this logic? Again, there are a lot of options. My personal favorite design is to have a kind of request/response system that abstracts the service layer. Something as cool as NServiceBus for a really disconnected asynchronous system, something as simple as Agatha for just abstracting out the actual service and putting the request/response logic in code, or maybe play around with ServiceStack (something I've been meaning to do) or another project, etc. Hell, you could just roll a plain old WCF or even SOAP service layer and nothing more. It's up to you.
At that point you're looking at a fairly procedural system at the service layer. This isn't a terrible thing. Think of the service layer like an MVC site. You send it a request, populated with some kind of incoming viewmodel, it does its domain stuff in all its object-oriented goodness, and returns a view in the form of some XML representation of an outgoing viewmodel. Now you have a repeating pattern. Your client-side applications are just great big views for your domain. The dumber they are, the more interchangeable and replaceable they are, the better.
This allows you to encapsulate various "business actions" in a unit of work at the service boundary. Given a request from a client application, either the whole thing succeeds or the whole thing fails. Wrap it up in good error handling and an application-level error/exception logger to give you all the details of the failed requests. (Imagine that every request can be serialized to a string and included in an error message. Now you have everything you need to recreate the error in a simple string, as opposed to asking users "what did you click on?" to try to recreate errors.)
If, instead, the back-end doesn't really share anything with different applications and each application is its own distinct entity entirely. At that point you don't really need to share all that logic behind the service layer, and it's entirely possible that you shouldn't try to make any kind of overlap. Is the data access the only thing that's behind the service? What about things like filesystem access or external web service access?
If the only thing behind the service is the data access, then you can keep your models and data access repositories in your client applications like you seem to be accustomed to and just swap out your repository implementations with implementations that internally reference and access the service layer. (This would be the second option in your GetEmployee example.) Properly abstracted, direct access vs. service access repositories can be swapped out trivially depending on where the application needs to live.
Of course, this leans a little towards a true persistence-ignorance approach, which can be dangerous. Performance implications need to be considered. Some piece of logic or unit of work on the back-end may hit the database several times to do several things. If this is happening across a service then that adds service overhead to each database call. So you'll want to address this on a case-by-case basis.
I guess I may be rambling at this point, so to get back to something concrete it really comes down asking yourself some questions about your domain. How persistence-ignorant can you afford to be? Do your applications share business domain logic? Do you need to access other non-database external dependencies behind the service only? There's no universal design that's always the right answer. You'll probably end up experimenting with various designs and homogenizing on a design that's right for your developers and your environment.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions concerning problems with code you've written must describe the specific problem — and include valid code to reproduce it — in the question itself. See SSCCE.org for guidance.
Closed 9 years ago.
Improve this question
When developing an application which mostly interacts with a database, what is a good way to start? The application requires a lot of filtering based on user input, sorting and structuring.
The best way to start is by figuring out "user stories" (or "use cases" -- but the "story" approach tends to really work great and start dragging shareholder into the shared storytelling...!-); on top of that, designing the database schema as the best-normalized idea you can find to satisfy all data layer needs of the user stories.
Thirdly, you may sketch layers such as views on top of the schema; fourthly, and optionally, triggers and stored procedures that might live in the DB to ensure consistency and ease of use for higher layers (but, no matter how strongly DBAs will push you towards those, don't accept their assurances that they're a MUST: they aren't -- if your storage layer is well designed in terms of normalization and maybe useful views on top, non-storage-layer functionality CAN always reside elsewhere, it's an issue of convenience and performance, NOT logical consistency, completeness, correctness).
I think the business layer and user-experience layers should come after. I realize that's a controversial position, but my point is that the user stories (and implied business-rules that come with them) have ALREADY told you a LOT about the business and user layers -- so, "nailing down" (relatively speaking -- agility and "embrace change!" should always rule;-) the data storage layer is the next order of business, and refining ("drilling down") the higher layers can and should come after.
When you get to the database layer you'll want to handle the database access via stored procedures. This will help give you additional protection against SQL Injection attacks, and make it much easier to push logic changes to the database layer.
If it's mostly users interacting with data, you can design using a form perspective.
What forms are needed for user input?
What forms are needed for output reports?
Once you've determined that, the use of the forms will dictate the business logic needed to be coded behind the scenes. You'll take the inputs, create the set of procedures or methods to deal with them, and output what is necessary. Once you know the inputs and outputs, you will be able to easily design the necessary functions.
The scope of the question is very broad. You are expecting me to tell what to do. I can only do a good job of telling how to do things. Do investigate upon using Hibernate/Spring. Since most of your operations looks like querying db, hibernate should help. Make sure the tables are sufficiently indexed so your queries can run faster if filtered based on index fields. The challenging task is design your DB layer which will be the glue between your application and db. Design your db layer generic enough so that it can build queries based on the params that you pass to it. Then move on to develop the above presentation layer. Developing your application layer by layer helps since it will force you to decouple the db logic from the presentation logic. When you develop the db layer, assume that not just your presentation layer but any client can call it. This will help you to design applications that can be scalable and adaptable to new requirements.
So bottom line : Start with DB, DB integeration layer, Controller and last Presentation Layer.
For the purpose of discussion, I'm going to assume that you are working with a starting application that doesn't have a pre-existing database. If this is false, I'd probably move the order of steps around quite a bit.
1 - Understand the Universe
First, you've got to get a sense of what's around you so you can really understand the problem that you are trying to solve.
User stories or use cases are often a good starting point. Starting with what tasks the user will try to do, and evaluating how frequently they are likely to be is a great starting point. I like to start with screen mockups as well, with or without lots of hands on time with users, I find that having a screen gives our team something really finite to argue about.
What other tools exist in this sphere? These days, it seems to me that users never use just one tool, they swap around alot. You need to know two main things about the other tools you users use:
(1) - what will they be using as part of the process, along side your tool? Consider direct input/output needs - what might they want to cut/copy/paste from or to? What tools might you want to offer file upload/download for with specific formats, what tools are they using alongside your tool that you might want to share terminology, layout, color coding, icons or other GUI elements with. Focus especially on the edges of the tools - a real gotcha I hit in a recent project was emulating the databases of previous tools. It turned out that we had massive database shift, and we would likely have been better starting fresh.
(2) What (if anything) are you replacing or competing with? Steal the good stuff, dump and improve the bad stuff. Asking users is always best. If you can't at least understanding the management initiative is important - is this tool replacing a horrible legacy tool? It may be legacy, but there may be the One True Feature that has kept the tool in business all these years...
At this stage, I find that things are really mushy - there's some screen shots, some writing, some schemas or ICDs - but not a really gelled clue.
2 - Logical Entities
Or at least that's what the OO books call it.
I don't care much for all the writing I see on this task - but I find that any any given system, I have one true diagram that I draw over and over. It's usually about 3-10 boxes, and hopefully less than an exponentially large number of lines connecting them. W
The earlier you can get that diagram the better.
It doesn't matter to me if it's in UML, a database logical model, something older, or on the back of a napkin (as long as the napkin is shrouded in plastic and hung where everyone can see it).
The earlier you can make this diagram correctly, the better.
After the diagram is made, you can start working on the follow on work that may be more official.
I think it's a chicken and egg question on whether you start with your data or you start with your screens and business logic. I know that you certianly want to optimize for database sizing and searchability... but how do you know exactly what your database needs are without screens and interfaces giving you a sense for the data?
In practice, I think this is an ever-churning cycle. You do a little bit everywhere, and then you change it all.
Even if you don't get to do a formal agile lifecycle, I think you're best bet is to view design as agile -- it will take many repetitions and arguments before you really feel it's "right".
The most important thing to keep in mind is that your first, and most likely 2nd 3rd attempt at designing the database will be wrong in some way. That might sound negative, maybe even a little rash, (it's certainly more towards the 'agile' software design philosophy) but it's important thing to keep in mind.
You still need to do your analysis thoroughly of course, try to implement one feature at a time, but try to get all layers working first. That way you won't have to do to much rework when the specs change and you understand the issues better. One you have a lot of data loaded into a system, changing things becomes increasingly difficult.
The main benefit of this approach is you find out quickly where you design is broken, where you haven't separated you design layers correctly. One trick I find extremely useful is to do both a sqllite and a mysql version, so seamless switching between the two is possible. Because the two use a different accent of SQL it highlights where you have too tight a coupling between the layers.
A good start would be to get familiar with Multitier architecture
Then you design your presentation layer.
In your business logic layer implement all logic
And finally you implement your data access layer.
Try to setup a prototype with something that is more productive then C++ for example Ruby, Python and well maybe even PHP.
When the prototype works and you see your data model is okay and your queries are too slow then you can start using C++.
But as your questions suggests you have more options then data and in this case the speed of a scripting langauge should be enough.