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.
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
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'm going to be doing a presentation on unit testing and in doing so I will touch on "design for testability" patterns. In other words using IOC containers, Dependency Injection, avoiding static methods etc.
I have a feeling my team will be cold to starting to code differently to accommodate for testing. So I was wondering if anybody knew of any real world examples of altering a design of something for no other reason then to make it easier to test.
I'm assuming this concept isn't uncommon in manufacturing, engineering and other professions, I'm just not familiar with any hard examples.
I imagine the development of the Saturn V rocket, Space Shuttle, Automobiles, Robotics, etc. must have some documented example of some design for testability or possibly the lack thereof causing problems.
Examples that have come to mind
I suppose having replaceable parts is a form of dependency injection, where as welding all the components together wouldn't allow testing them individually.
Perhaps the OBD2 port on modern automobiles because it makes it easy to check if any systems have issues.
Many electrical surge protector have a Test button to check the correct functionality. It is a very clever form of testing, because it's not only in the hands of the developers, but also of the final users.
Another example: many control report lights (in particular in critical environments, like nuclear power plants and so on) have a button to turn them on and check if they are still functional. The same for many appliances using LED displays.
Batteries have a power indicator, so that you can test them before buying.
In sugar refinement, you monitor many steps of the production (sort of breakpoints) to assess the quality of the product. The plant is designed so to provide these testing breakpoints for easy accessibility by a human sampler (normally not well paid).
Finally, car makers include all sort of diagnostic. A car repair shop has a computer to perform full check on the status of the car. It's a sort of "after the fact" debug log, so not really "preventive testing", but still very useful and the inclusion of it is a real world "design for testability".
The main difference, however, between real-world testing and software world testing, is that real-world testing can ruin the product, to the limit of being destructive. For this reason, the faulty-to-good ratio is assessed via destructive sampling and analysis. In software testing, you never have destructive testing (unless you are a sadistic programmer with evil intentions)
If a set of components have been built so they can be tested, it is likely that they will be more modular and loosely coupled. For example it is easier to test code that uses an IOC container rather than a Service Locator as collaborators can be simply mocked and injected.
This separation follows into development. As the type has no hard dependency on its collaboraters, it allows composition of those parts in a different structure, which means it is simpler to refactor/respond to new requirements. You will also have more confidence in any refactoring as you have a suite of tests to verify your changes against.
Taken together this means in my experience that code written for testing is quicker and easier to modify, which results in less work for me, which I like.
Some real world examples of components designed for testing (themselves or other things) to avoid bigger problems down the line:
Smoke detectors
RCDs (residual current devices)
Pre-flight engine checks in aviation
Personal Breathalisers
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