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.
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 9 years ago.
As someone who wasted weeks this Autumn to configure and reconfigure IIS servers for WCF, authentication, making EntityFramework behave etc, I really want to use ServiceStack in the new upcoming project.
I want to go all-in, i.e. I would like to completely skip Microsoft specific stuff this time.
I am looking for a real-world example using ServiceStack, I have been looking at Rockstars and SocialBootstrapApi, but I want something bigger.
My requirements:
It should be at least be two subprojects, one containing the web part, and one the business logic.
I do not expect any ServiceStack stuff except ServiceStack.OrmLite and some common things in the business logic part
Unit tests for business logic
Unit tests for ServiceStack services
Do anyone know about such a project where I can look at the source?
It sounds like you're looking for a prescribed n-tier architecture with an expectation of how it should be built. The fact you're using ServiceStack is a red-herring here, as a ServiceStack service is just a standard, auto-wired C# class that's completely mockable and testable in isolation (so you you would test it as you would any other class) or test it as an Integration Test using a self-hosted ServiceStack HttpListener.
I personally dislike prescribed architectures as I prefer to re-factor my code-base as it grows and only add architecture and delegation as needed. I provide examples of how I separate layers in my ServiceStack services and describe some of the different levels of architecture I commonly have within the same application in this thread. The one thing that ServiceStack tries to encourage is to keep your Service Models in a separate and largely dep-free assembly that's de-coupled from your implementation.
OrmLite doesn't require any special attention compared to any other DAL either. If you choose to encapsulate it inside a Repository class then you're left with a standard C# class (i.e. the Repository) that just accepts and returns clean POCOs. Depending on your preferred method of testing your data access layer, you can choose to mock the repository when testing your services or choose to use an in-memory Sqlite db and mock the RDBMS database with test data for integration tests that also tests RDBMS access.
Basically ServiceStack embeds an IOC and promotes clean Dependency-injected C# services allowing you the freedom to test your services in the preferred style you're already accustomed to. i.e. you shouldn't need to change your architecture or testing strategies to support ServiceStack as it should already give you the freedom to develop services as you normally would.
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
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
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.
When should I use specs for Rails application and when Cucumber (former rspec-stories)? I know how both work and actively use specs, of course. But it still feels weird to use Cucumber. My current view on this, is that it's convenient to use Cucumber when you're implementing application for the client and do not understand how the whole system is supposed to work yet.
But what if I'm doing my own project? For most of the time, I know how the parts of the system interact. All I need to do is to write a bunch of unit-tests. What are the possible situations when I would need Cucumber then?
And, as a corresponding second question: do I have to write specs if I write Cucumber stories? Wouldn't it be double-testing of the same thing?
If you haven't already, you might want to check out Dan North's excellent article, What's in a Story? as a starting point.
We have two main uses for Cucumber stories. First, because the story form is very specific it helps focus the product owner's articulation of the features he wants built. This is the "token for a conversation" use of stories, and would be valuable whether or not we implemented the stories in code. Second, when the process is working well enough that we have complete stories before we begin writing the feature (more of an ideal that we strive for than a daily reality), you have your acceptance criteria spelled out clearly and you know exactly what and how much to build.
In our Rails work, Cucumber stories do not substitute for rspec unit tests. The two go hand in hand. In practice, the unit tests tend to drive development of the models and controllers, and the stories tend to drive development of the views (we tend not to write rspec for our views) and provide a good test of the application as a whole from the user's perspective.
If you're working solo, the communication aspect may not be that interesting to you, but the integration testing you get from Cucumber might be. If you take advantage of webrat, writing Cucumber can be fast and painless for a lot of your basic functionality.
Think of it as a cycle:
Write your Cucumber feature, then while developing the pieces for that feature, write specs to complete the individual components. Continue completing specs until you've written enough functionality for the feature to pass, then write your next feature.
My take is that it's a bad idea to use Cucumber in most situations due to the costs in productivity its syntax incurs on you. I wrote extensively on the topic in Why Bother With Cucumber Tests?
A Cucumber story is more a description of the overall problem your application is solving, rather than if individual bits of code work (i.e. unit tests).
As Abie describes, it's almost a list of requirements that the application should meet, and is very helpful for communication with your client, as well as being directly testable.
Nowadays you can use rspec with Capybara and Selenium Webdriver and avoid having to build and maintain all of the Cucumber story parsers. Here is what I would recommend:
Write out your story
Using RSpec, I would create an integration test ex: spec/integrations/socks_rspec.rb
Then I would create an integration test which includes a new describe and it block for each scenario
Then I would implement the minimal functionality require to get the integration test and while going deeper back (into controllers and models, etc) I would TDD on controllers and models.
As you come back up your integration test should pass and you can continue to add steps to the integration test
repeat
One thing to note, however, is that the controller and integration tests have overlap that may not be necessary so you have to use your best judgement so you do not waste your time.
Also, once you find your groove you will find it most enjoyable to develop using BDD, until then don't feel guilty if you don't feel like you are doing it perfect and don't over think it. You will do great!
But what if I'm doing my own project? For most of the time, I know how the parts of the system interact. All I need to do is to write a bunch of unit-tests. What are the possible situations when I would need Cucumber then?
You still need Cucumber. You need it to document how you see the system working, and you need it to make sure you haven't broken functionality when you change things.
In other words, you need Cucumber stories for the same reasons as you need unit tests -- they just work on a higher level of abstraction.
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 been given the task of laying the groundwork of a SOA for my client. The goal is to open up various processes in an end-client independent way and also to make data available offline e.g. for reps visiting customers.
I do have extensive experience with J2EE (Websphere) and web services but I would appreciate advice on how to build up such an SOA.
Where are the pitfalls? What about security? How finely granulated should services be? etc.
Links to tutorials and book recommendations would also be useful.
Thanks!
Pitfalls
Versioning/backwards compatibility: it gets really hard to change a contract once you have loads of clients. I have seen many sites version the APIs by introducing the version in the URL
Granularity
Each service should be reasonly self-contained (don't expect people to do 3 calls before they get what they need)
Platform Independence
Try to give more than one way of accessing your APIs (WS, JSON, REST...)
People can't agree on what SOA actually means.
http://martinfowler.com/bliki/ServiceOrientedAmbiguity.html
(although consensus may have grown since that was written)
I suggest quizzing your client to find out exactly what they mean - if anything. Then give them something that actually provides business value, while ticking any SOA boxes that might coincide with that effort.
Call me a SOA-skeptic. Fowler's lament still seems right on.
I would focus on the more general problem: your client has 2 or more applications that have to collaborate together. Look at old school integration patterns.
(source: amazon.com)
Found this IBM Redbook (#sg246303) which is quite a good introduction to the basics of SOA.
As Alan said, I'd start reading the Enterprise Integration Patterns book. There are a number of ways to implement them either using a messaging system directly such as JMS or using open source projects like Apache Camel, for example see the pattern catalogue.
I'd also look at understanding how to build good RESTful services using JAX-RS with Jersey as a simple way to expose resources for your systems to anyone on the web from any language/platform easily without falling into the SOAP/WS-* deathstar :)
Get an ESB (enterprise service bus): Mulesource is a good choice (Opensource, Mature, yet bleeding edge) . Once you understand it, you will understand SOA.
The goal is to open up various
processes in an end-client independent
way and also to make data available
offline e.g. for reps visiting
customers.
The second half of that isn't really an SOA topic, it's more of a replication to mobile devices problem. I would stay far, far away from trying implement a buzzword and focus on the problems that you are stating. Web services are good way to open up process to client independent ways.
So far the best book I found is SOA Compass also available on Amazon