New answers tagged

1

In the expected form of Interactions And that depends on the user. To a user that understands web APIs and programming, sending a POST to /hobbies/{name}/increment is similarly intuitive to clicking a button in a UI. Even more, to such a user the API may be much more comfortable because it is magnitudes easier to integrate into other automations. However, ...


1

I think you may be asking the wrong question. Good practice or bad practice for a Dockerfile, because they have so many different applications, depends on what exactly you do with them. However, if your real question is: How should I deal with this potential for breakage? The answer is, only build your docker image once, as the very first step of your ...


1

Typically, having multiple implementations of some feature would suggest a Strategy pattern: https://en.wikipedia.org/wiki/Strategy_pattern In your case, the situation is a bit more complicated, because one class (for each type of camera) might be able to do multiple things: record, zoom, flash, etc. What a specific camera can do, is a responsibility that ...


3

Can you nest them? i.e. Interface IZoom { Tuple<int, int> Range {get;} // ... } Interface ICamera { IZoom Zoom {get;} // ... } So if there is no zoom the property is null? It doesn't make the cleanest of code, since you have to test all the time if the feature is present. On the other hand, if you are drawing the item, you have to ...


1

I think since you are targetting a robust system and concern about performance, it is better to use a queue system for Job execution and set up priority. I am not seeing any fault or problem storing ER and using triggers from the database but my question is why should we use triggers when we can use a fault-tolerant job queue system which is ideal for such ...


4

Exactly-once guarantees can be had the easiest with a (option 1) message queue system. This also neatly solves the problem of retries, as failed operations can be stuffed back into the queue, or a dead letter queue can be used. You can technically run n agents on the problem (option 2), and each agent only processes users with ((int)userId) % n == agentId). ...


1

I've always liked NorthWindTraders as a clear example of how to properly use EF in a multi-layered application, without needlessly resorting to rolling your own UoW or persistence layer (which is a bigger hassle than it is a solution. Who is responsible for calling SaveChanges? That depends on who is doing the data operations. If your service calls ...


0

First a clarification : In a multi-tenant architecture, one instance of an application is shared between several tenants but the data is compartmented so that each tenant only see its own. This can be achieved with different patterns: with a database per tenant with a multi-tenant database with a shared database, the application taking care of the ...


1

If the server decides when, how or how often to retry, then you can change your retry strategy at any time without having to modify the client. You may even use different strategies on different weekdays or at different times of the day; whatever suits your needs. On the other hand, a server can only retry promptly as the client needs to uphold a connection ...


0

The primary reason to use a presenter is single responsibility/separation of concerns. The situation with web APIs is a little murky as modern frameworks will do content negotiation and take care of the wire format (say JSON vs XML) for you. I'm strongly in favor of the use case calling the presenter directly, as this means the use case response model is "...


3

I guess Stephen Cleary expects a ports and adapters architecture to do all I/O in the outer layers and to pass in the results of these operations to the domain objects. In your example, this would be simple: pass in the content to the domain object rather than injecting IContentRepository: public class MyDomainObject { public void Foo (Content content) {...


0

I've had this discussion with a coworker recently - it's the nature of microservices to have functionality available as REST services (no longer in-process). If that's not practical, don' put it in a microservice (or change the API). Let's say you have AddUserToGroup() and IsUserInGroup(). The former probably happens relatively rarely and the cost of the ...


1

You need to make the adapter call to your domain. Async code can call both sync and async code. However, when sync code calls async you run into trouble. Simplest way to fix this is to pass a callback. How does the flow of execution on your project go? The code that does your dependency injection can be async, so it can call both sync and async code. See ...


1

It is true that if you start using async-await it spreads as a zombie along application pipeline and you will be forced to use async everywhere. Try to approach design from a bit different angle - domain logic care only about data. So we can put all IO related code outside of domain layers as close to the top layers as possible. 1 Load required data ...


2

The Dead Letter Collector seems to be doing two things: handling undeliverable messages, and handling messages that need to be retried (delayed delivery). This could be split into two collectors, particularly as the name "Dead Letter" implies (to me) that anything that goes there will never leave. Messages that can't be delivered for any reason can be sent ...


1

Shared entity is a very common problem in microservices. Theorists of microservices argue that there shouldn't be any shared entities and it's a bad design if you have them But unfortunately that's a very common case. since a storage of a microservice is only accessible by that particular microservice hence there is no other way to access it and for shared ...


2

Really you are just rearranging code to your personal tastes. You can have various arrangements such as: Object.Deploy() Deployer.Deploy(object) Deployer(object).Deploy() Personally, I don't like the Deployer(object).Deploy() because it leaves behind a useless Deployer object. Object.Deploy() is nice for things where the Object hangs around and has ...


0

You need to wrap the existing data in an api of some kind. So that whenever it is updated you have a point where you can intercept the update and replicate it to your new system. Then you can simply manually populate the new system and expect it to stay in sync. Now you can get to the bit you want to improve, it can call this new API for the data it needs ...


1

But what if someone in the front-end decides to send hundreds, thousands, or millions of these duplicated tags all at once? Can you handle it? (On both sides?) Imho, the easiest way for handling this is to make it so that, for example, the user interface in the front-end, uses a "chip-like" entry of data for these tags, that can come from a dropdown or ...


3

I have seen many descriptions of the Facade Pattern state that it should provide a single interface into a complex subsystem. Segregating the interface seems to violate that axiom. It would be more accurate to say that a facade provides a simpler interface to a complex subsystem. A facade composes several low-level operations into a new higher-level ...


1

I'm noticing some fundamental issues with the basis of your question. The first issue is architectural. Strictly speaking, requirements changing on the front end (GUI) should be orthogonal to the other components of your application. Consider a bulletin board application. If one customer wants a dashboard with widgets and another wants a streaming feed, ...


0

Yes. No mediator is required. Assume the following interface: public interface ICommandHandler<in TCommand> where TCommand : ICommand { void Execute(TCommand command); } Now you have the following command: public class CreateCustomer : ICommand { /* ... */ } And a controller (example from ASP.NET MVC): public CustomerController { ...


1

The SRP is not about doing one thing, but about reasons to change. The case that you describe is on one side a Tree class that manages elements, and on the other side a State class that makes use of a specific tree. At first sight, creating an overload to enrich Tree with an add at root level does not seem to break the SRP: this overload does not ...


5

Common e-mail server software (postfix, sendmail, presumably exim but I didn't check that one) supports forwarding to programs via pipes, so this isn't esoteric at all. Ticketing systems such as Redmine and mailing list managers such as GNU Mailman use it all the time. If you prefer not to run your own e-mail server, you can programmatically access ...


2

You can't "ditch the repository pattern" if all your classes are repositories despite the naming. Here it looks like both your datamapper and service are simply repositories. Flatten them out and call it a repository. Or lose the service layer. If it has no logic you don't have a service. The purpose of a layered design is to separate out parts of your ...


1

I think the closest you're going to get is something like OpenMP for C, C++, and FORTAN. This library allows you to parallelize some constructs like for loops simply by inserting a pragma or two before the code block: void simple(int n, float *a, float *b) { int i; // This assumes the blocks pointed to by a and b don't overlap #pragma omp parallel ...


0

This is the fundamental of all modern OS, the abstraction to virtualize the CPU is the Process and also the Lightweight Process, which is more commonly known as Threads and an even lighterweight version commonly known as Fiber/Green Threads. Each program running inside a process (or a lightweight process, or green threads) is running inside a virtualized ...


2

In most cases web hook is superior to polling. The only aspect that polling is unarguably better than webhook is that polling is usable when the client is behind a NAT and therefore can't make a listening port to receive a webhook. One case when web hook doesn't bring any advantage, but a polling architecture is signficantly simpler to implement, is when ...


Top 50 recent answers are included