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
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 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.
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.
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 work in a medium size financial company where all our applications talk to each other using SOAP and we only use JSON for AJAX requests from web sites.
Recently in a new project planning session, someone asked me why do we have to use SOAP for inter-application communication? Why not use JSON or even custom data format? In my heart I felt these alternatives are not "Enterprise-ready" but actually I couldn't think of a very compelling answer as to why they are bad.
The only two advantages of SOAP I can think of are tooling and security.
Modern IDEs such as Visual Studio have built-in utility to generate classes from WSDL definitions, which you don't get if you use JSON or custom data format. In terms of security, SOAP has well-defined security standards that are not available in other data format standards.
What do you think? do you use JSON as the data exchange format between applications?
The reason for JSON is simplicity. It's easy to read, easy to understand, has little overhead, and has implementations in just about every language.
To call something "enterprise" capable is a bit crazy, IMHO. It's just a data exchange format. Whether it's SOAP, XML, JSON, whatever, it's just a communication format.
Tooling is nice, I admit; auto-generated classes are great. But on the other hand, you get a lot of flexibility when you manage your classes by hand, and generally, it's not that difficult to do.
Security is a non-issue in my mind. Your data format should have (again, IMHO) nothing to do with your security. That needs to be at a different level entirely. While SOAP has some security extensions, etc, I think for the most part, they just provide a lot of unnecessary complexity. Ever tried reading some of the specs for the WS-Security? Yikes. How about just using JSON+HTTPS - easy, everyone supports it, and it works like a champ....
Now, that's not to say it's the right solution to every problem, but if you're just looking for data interchange, I'm sold.
Personally, I love JSON as a format, and use it all the time.
IMHO, there is one big reason everyone sticks with SOAP instead of using JSON. With every JSON setup, you're always coming up with your own data structure for each project. I don't mean how the data is encoded and passed, but how the data format is defined, the data model.
SOAP has an industry mature way of specifying that data will be in the form Cart is a collection of Products and each product can have these attributes, etc. A well put together WSDL document really has this nailed. Heck, it's a W3C specification.
JSON has similar ways of specifying this data structure. A JavaScript class comes to mind as the most common way of doing this. A JavaScript class isn't really a data structure in any kind of agnostic, well established, widely used way. Heck, JavaScript really only executes in one environment, the browser.
In short, SOAP as a way of specifying the data structure in a maturely formatted document (WSDL). JSON doesn't.
UPDATE: I have to say, I'm amazed by the number of down-votes this answer has gotten over the years esp given its accuracy at the time. I don't mean to hate on JSON, but after reading a recent article, I continue to stand by my previously made points. Meanwhile, JSON-RPC seems to be practically abandoned from a standardized format perspective (version 2.0 a proposal from 2010) and no other JSON protocols seemingly close to the level of SOAP's standardization. (Personally, this hasn't stopped me from embracing JSON-RPC 2.0 in production environments. I just would never use it in a proposal to a Fortune 500 company.)
To be clear, from an internal use perspective, JSON is GREAT. Lightweight. Fast. Widely used. Reasonably human-readable. But for enterprise, where multiple data streams are frequently merged. And data format specification between dozens of departments is necessary. XML is the established leader.
JSON does entail more effort that SOAP XML, but it typically produces much smaller packets, and is therefore more scalable. It is also (in my subjective opinion) vastly easier to read, while debugging, sniffing the wire, etc.
One major reason has nothing to do with technical reasons.
A lot of "enterprise" systems are being sold to big stuffy "enterprise" clients. The client demands SOAP and that's what they get.
What are their reasons? Sometimes it is very pragmatic: their team is familiar with SOAP and they have many existing SOAP services (and this team would maintain the product after it is delivered). Sometimes it's not: they read it in some article and they have their minds made up.
I wouldn`t use SOAP unless the data is large or its structure complex. The JSON, AJAX, PHP or even the REST doing well.
I am using SOAP to communicate from a JavaEE (Jboss Ejb 3.1 #WebService) Backend to MS C# Winforms.
Maybe in the future there will be SOAP (version X) that will use compressed JSON as data exchange format that will make it fast and ideal.
Restful is good for simple data exchange;
Ideal for javascript Ajax request in a interactive Web page.
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 12 years ago.
Can somebody point out the advantages of Clojure and what type of applications is it suited for ?
I don't intend to compare it to any languages as such. As a language in itself what is it suitable for ? My intention is to know the right tools for the right job, and where does clojure fit-in in that kind of scenario.
Advantages:
all the benefits of functional programming, without the purity straitjacket
lispy: allows dynamic, compact code with late binding, macros, multimethods
Java interoperability
can code functions to sequence abstraction instead of to specific data structures
concurrency goodies baked in: functional data structures, software transactional memory
runs on the JVM: portability and fast garbage collection
Suited for:
bottom-up design
embedded languages
highly-concurrent applications
Probably not suited for:
cases where you want static typing
if you want the language to be amenable to static analysis
anything that needs a fast startup time
hordes of clueless Java monkeys
In general I find as strong points for clojure (in no particular order):
1) The REPL to try things out interactively.
2) Everything is immutable by default and mutability has several well chosen standard patterns to modify state in a safe way in an multithreaded environment
3) Tail recursion is made explicit. Till there is proper support for tail recursion on the JVM this is probably the best compromise
4) Very expressive language which favors a functional approach over an imperative approach.
5) Very good integration with the Java platform making it painless to mix in Java libraries
6) Leiningen as a build and dependency management tool together with the clojars site
Ok, point 6 has nothing to do with the language perse, but definitely with my enjoyment of using it.
Regarding applications it targets multithreading applications, but the way things go right now that could mean about anything, as everywhere people try to keep all those cores busy while the user is not waiting. On the other hand apparently a lot of people use it to deploy to Google App Engine which is radically SINGLE threaded.
The functional approach works well in my (limited) experience for implementing data transformations and calculations. Where information and events can be 'streamed' through the application. Web apps fall largely under this category where we "transform" a request into a "response".
But I still have to use it in real production code. Currently I use it for personal projects and prototyping/benchmarking stuff.