Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

In my experience there isn't an issue. It all comes down to how well you design your application. Here's the interface to a service in a fun side project I'm currently working on (comments removed):

    public interface IAnalysisService
    {
        Guid CreateAnalysis(Guid ownerId, string name);
        void LoadingAnalysisInputs(Guid analysisId);
        void RequestAnalysis(Guid analysisId, string number, IEnumerable<Records> inputs);

        Guid CreateAndRequestAnalysis(Guid ownerId, string name, string number, params Records[] inputs);
        Guid CreateAndRequestAnalysis(Guid ownerId, string name, string number, IEnumerable<Records> inputs);

        Analysis FindAnalysis(Guid analysisId);
        Analysis FindAnalysisForProcessing(Guid analysisId);

        void CompletedAnalysis(Guid analysisId, AnalysisResults results);
        void FailedAnalysis(Guid analysisId, string reason, params object[] args);        
    }
These methods implement some business rules, do some database work and throw a few messages onto a service bus. Why is it so hard to believe that the database implementation for any of these methods affects the consumers? Here's a sample implementation:

        public void FailedAnalysis(Guid analysisId, string reason, params object[] args)
        {
            AnalysisRepository.Failed(analysisId, string.Format(reason, args));

            Bus.Send(new AnalysisCompleted {AnalysisId = analysisId});
        }
I don't see any obvious bugs, complexity or leaky abstractions.


Your comment is lost on most people here - Ruby doesn't have interfaces.


And ruby doesn't have macros that would make such a db switch even simpler.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: