New answers tagged

1

Also, don't be afraid tot tell me it's a silly idea. It's a silly idea :P And here's why: Data caps. The primary hog when it comes to data are things that happen in the background without any user's consent. You wouldn't want to be leeching off a person's data. Battery and heat. Of course, processing takes up resources and resources doesn't come free, ...


3

This looks like it will eventually bite you in the behind, as in that it's very cluttered and doesnt really provide good maintainability. I would have organized it like this: Each resource (model) gets its own class file containing its attributes, like: Model/Article.cs Id Name Price Each resource collection has a class containing methods for ...


1

In your case where you are using microservices you should use the shared cache. The reasoning is that one of the key benefits of microservices is that you can scale them to multiple instances. If you do this and an incomming request hits service instance 2 instead of 1 instance 2 could benefit from the cached result.of a previous call to instance 1 Unless ...


2

If what you are after is the elimination of global state in your application then the static keyword definitely sucks to have in your code (you say you don't like it, so I'm going to assume you know the disadvantages the static keyword brings to application development). Considering the cache issue, whether it is in-process or out-processed to a system such ...


5

As always, one must differentiate: what information is to be stored in the cache? I always go with these simple rules: Information every webserver instance can calculate for itself should go into an in-RAM cache as these need to be accessible ASAP on request but have no need to be shared (never change or do not contain information relevant to other ...


0

You are close with your first point, but I think a better approach is: Design your data model (not the database schema) with input from as many disparate sources as your project can fund. You need the opinions of developers, architects, testers, users and business analysts. You might use a UML tool, but many projects just use post-its on a large sheet of ...


2

It also happens in web developments. So often. Webservice data model should not be conditioned by UI. It make it really unflexible and hard to scale. In terms of web developemnt, in MVC pattern, C (Controller) is the facade in charge of transforming any business data model into a DTO. Such DTO's are neither designed for UI. They are a summary of the real ...


1

Common solutions to this class of problems: Use HQL. In DAO methods that are for specific purposes, it is easy to use a custom HQL with (left) join fetch to specify exactly what data you want to pre-populate in the model. Manually reference lazily loaded collections. E.g. manually call user.getOrders().size() in some DAO methods. This has the same effect ...



Top 50 recent answers are included