225 reputation
15
bio website
location
age
visits member for 1 year, 7 months
seen Mar 22 at 8:08

May
8
awarded  Yearling
Mar
19
comment Optimistic & Pessimistic Programming - Ensuring multiple tasks are called only once for specific record
@RobertHarvey No. As I interpret the question, the main problem is that you must not send the same records to the web service twice but since systems are unreliable, there's no way for you to keep track of whether you've already sent the records. So the pretty solution to this issue would be to allow the client to perform the same web service call many times with the same data without side effects. This is idempotence and its what you use to solve this types of issue. More info here: servicedesignpatterns.com/WebServiceInfrastructures/…
Mar
19
comment Optimistic & Pessimistic Programming - Ensuring multiple tasks are called only once for specific record
@DocBrown. As a side note: In my opinion, the only sane way to handle this is to implement idempotence throughout the system (call site, web service site). If you are going to do changes to the web service, you may be better of implementing idempotence, rather than adding "Check support". This will lead to a much cleaner interface where you don't have to first check if you have done something, but rather just re-do it if some part failed the first time. Implementing 'Checks' will get messy as the system grows imo.
Oct
8
asked Workflow versioning
Sep
29
awarded  Critic
Sep
24
revised Is it possible to build a custom email client for Gmail using Java APIs?
added description of link
Sep
23
awarded  Teacher
Sep
23
answered Is it possible to build a custom email client for Gmail using Java APIs?
Sep
14
comment How do I create a simple yet complex business layer?
Regarding SOLID. Say I have a CreateCustomer method which launches 10 sub-process. I may add new stuff to this method as I get new sub-processes, I may get rid of stuff in it and I may change order of the sub-process. Wouldn't this go against the Open/closed principle since I have to modify the function if I want to add new sub-process? Using something like plug-ins/observer pattern would make it possible to extend complex processes without changing any existing code but merely add more plug-ins/subscribers/observers. I see that this may add complexity, but I'm not convinced in any way.
Sep
14
comment How do I create a simple yet complex business layer?
Thanks but I think you are missing my point a bit. Creating a customer in our software is a complex process. I want this process to be as easily understandable as possible. It's not a matter of hiding away code, it's a matter of placing code and logic in the most clear manner as possible, making it easily extendable and testable. I was thinking that maybe separating sub-process into their own components could make them easier to test and understand on their own. I agree that a plug-in/observer-based system may not accomplish this which is why I'm here asking the question in the first place.
Sep
14
comment How do I create a simple yet complex business layer?
Sorry, I've updated my post. Whether I call it CustomerRegistration or CustomerManager is not the main issue. Our Customer*/User* classes have a weird suffix which I didn't want to confuse you with, so I replaced that with the "Registration"-suffix. But in reality, our class names are closer to "*Manager" than "*Registration". I agree that having a Delete() operation in a *Registration class could be confusing.
Sep
14
awarded  Editor
Sep
14
revised How do I create a simple yet complex business layer?
deleted 35 characters in body
Sep
14
comment How do I create a simple yet complex business layer?
We already try to fairly aggresivly refactor into smaller methods, but if creating a customer consists of 10 sub-processes and each of this sub-processes are depending on configuration, it tends to get a bit complex even after refactoring.
Sep
14
asked How do I create a simple yet complex business layer?
Aug
14
asked How much should we spend on improving software security?
May
10
comment Large teams with layered application
Let's say we do it like this. So to be able to deliver a new feature in the product, I assume that people from Team UI, Team Backend, Team Persistence would have to work together since changes are needed in all parts. Wouldn't this then be the actual team? I would say that for these people to be efficient, they should sit together and implement the new functionality together as a team. Would you disagree with that?
May
10
awarded  Supporter
May
8
awarded  Student
May
8
asked Large teams with layered application