Tag Info

New answers tagged

3

Is consistency important? If you consider saving data in SQL, why not go with SQL all the way? Anyways... aggregate functions like count is not a feature of Table Storage, so you either need to fetch all rows and count "client side" (can be very slow), or figure out a way to cache the "count" in another entity. It really depends on your data and ...


1

I agree that web app must be the only one accessing mysql. So web app must inevitably provide some sort of api that let your public web api access relevant data. This API is a contract between web app and mysql that allow them to be developed separately without breaking. The complexity and flexibility of this API must reflect your business needs but keep ...


0

The speed of downloading and uploading small files can easily be circumvented by putting several files into an archive (eventually with level 0 compression if files don't need to be compressed, which is the case for example for JPEG files). If the user uploads hundreds of files, this will result in two-three large files. If the user needs to upload only one ...


0

The policies you're citing concern themselves primarily with what has responsibility for maintaining the cache and deciding when and how to read data from the main memory. In Cache Aside, the application assumes the responsibility. The application will look at the cache and see if it has the data it needs. If the cache doesn't contain the required data, ...


1

Assuming that you're already in this situation: Store form config in a DB and reference the version number, rather than serialize it to Json over and over again. Don't use conditionals, just have completely separate html/js pairs and backend end points. You might have to do some internal rewrite if you want to have the forms appear under a single url. ...


0

The answer depends on some assumptions not described in the question: 1. You don't have the liberty to change the vendor or internal API 2. The grouping has to be performed in a single transaction. i.e., how strict should the API be against vendor API failures. What happens if 1 vendor fails and the rest succeeds. Do we still consider this a success or ...


1

At the topmost level, you can use a fold to feed the output of the last step into the input of the next step without having to give it an intermediate name that gets reassigned. Basically, at each step you create a whole new scope. This part is a lot easier with functional reactive programming or actors. Below that level, the key insight is because of ...


3

To reflect the changed state of an object (I will call this object now and reference with this to the OOP paradigm) you can return this object again which in itself is immutable again, e.g. playerOne = doSomeMove(playerOne) Basically this is the idea behind the state pattern. With this the single object is immutable but your changes are reflected by ...


3

I think that this is the perfect fit for Bounded Context pattern from Domain Driven Design. Large models don't scale well, it's better to split them into smaller models (bounded contexts) and explicitly declare their relationships (common entities, interactions between bounded contexts etc.) In this case you would have two bounded contexts (sales and ...


0

Some IOC containers (for example Spring or Weld) can solve this issue using dynamically-generated proxies. Proxies are injected on both ends and the real object is only instantiated when the proxy is first used. That way, circular dependencies aren't an issue unless the two objects call methods on each other in their constructors (which is easy to avoid).


3

I've had the same problem and "solved" it by modelling REST resources differently, e.g.: /users/1 (contains basic user attributes) /users/1/email /users/1/activation /users/1/address So I've basically split the larger, complex resource into several smaller ones. Each of these contain somewhat cohesive group of attributes of the original resource which ...


0

This does not mean J2EE applications are based on skimpy models it just that you can implement any more complex model using only entities, attributes and relationships. In the same way you can implement any control structure (for each, while, do until) using only if and goto. There is no need for the more sophisticated concepts to be part of the ...


3

I see this in the .NET world as well and I have so far identified a handful of reasons as to why this happens (I also do not prefer anemic data models). Old code. People didn't know better and it's too expensive to rewrite. Misinterpretation of the DRY principle. People want to use their objects as contracts and send them over the wire as XML/JSON and then ...


1

StartDate and EndDate of what?.... the school year? Ok: public class SchoolYear { StartDate = DateTime.Now; EndDate = new DateTime (2016, 6, 23); } Object Oriented Programming is about, well, objects: Put properties in a class to appropriately describe/define what it is. Write methods against those properties to describe/define what it does. As ...


0

Typically you domain objects would cross layers and also process boundaries. So your Domain objects which are typically POJOs are essentially the contract between layers and processes. Contracts should define the expected structure of inputs, outputs (and exceptions) not the business logic. This is true weather you are writing enterprise code or otherwise. ...


0

I think the rule of thumb should be the following. If an item itself is unthinkable without being related to sales or inventory, you should go for option 1. If an item can exist without any relation to sales/inventory or this relation is not really strong in your architecture, you could go for option 2.


0

I came up with a "hybrid" solution. And you may give it a thought. I understand it's not desireable to modify 3rd party database, or, sometime it is not even possible because you don't have access to client sources, right? In my case, source data did not have anything I can "reference" like "updatedOn" or any reliable timestamps or logs.. I also needed to ...


0

Django will help you in that manner. You will redirect multiple sites to your Django instance, and the Django instance will use the API that can help you with saving through economies of scale, with VM costs/ API subscription costs, etc. In this context, I am assuming that you are not using limited free tiers, or you do not have complicated SLAs with your ...


0

Yes. It is much better then how it was done previously. Moreover Django is also the right tool to do it. The reason for the same is, when we look at the base of the framework i.e. Django is this case is written in Python. Python believes more in Readability rather then writing the code itself. So, yes the things you have done is much better in simple terms ...


1

I do not think making decisions about if trial time was exhausted on client is a good idea. This can be easily fooled and can't be calculated with some precision. Since you have a web application, I guess, it would be much better to limit a number of API calls a trial user can make without payment. You can make some tests and map an average number of API ...


1

I couldn't convince my boss yet that this is a bad idea, am i wrong here? I feel like a web app is not the right tool for this job. And if this is indeed a bad idea, what would the best way be for me to clearly explain him that? I am really not sure this is a bad idea. To me it sounds like a good idea because your customers will get what they want ...


0

Is there any standard way of solving this kind of synchronization problem? I believe not, but I can propose a system redesign. Make two API methods instead of one: Method returning event ids for events currently scheduled for the specified date interval Method returning event details together with updated_at timestamp for a given event ids If a ...


0

This is a very very broad question... Too broad to really answer well... Are we talking about things like days of the week? are we talking about things that matter only to the UI, and the Business Logic doesn't care about? are we talking about values that arise from real Business Logic? Some default values come directly from Business Logic. Eg. employ ...


0

In a MVC type web application, default values being submitted with a form request should generally be placed in the view directly. This is to say that the controller shouldn't care what arrives, so long as the parameters are valid (and as these things go, it is always a good idea to check user input). However, it is also true that default values can get ...


1

I asserted that default values are business logic and should be tested as such in a recent code review. It's not hard to pull the initialization logic out into whatever component owns "presenting" your view. In essence, ask yourself why a default value should be treated any different from a.. I don't know.. "normal" value. If you concede default values are ...


1

Use 200 Ok The setup you propose is common with a service orientated architecture (SOA). When using asynchronous messaging you typically have a flow like: --> Request <-- Delivery acknowledgement <-- Process acknowledgement --> Delivery acknowledgement It is typical to use 200 Ok for a successful delivery acknowledgement. I would expect this ...


6

The successful creation of the task to do whatever was successful. This means that one should be looking in the 2xx block of the response codes. In this block one jumps out as the correct answer quite quickly: 202 Accepted The request has been accepted for processing, but the processing has not been completed. The request might or might not ...


1

You miss the opportunity to report errors that may occur while processing the message. That way the consumer of your service can never be sure if the call was successful.


1

Overview This is one way to solve that problem. imagine a request. It contains information defining the request (is it an update of data, or is it a request for the current data), and way for the requester to be notified that the request has been actioned, and of its results. Next up, you have a queue. You place the request into the queue, and at some ...


0

For inspiration, you might want to have a look at functional programming, or more precisely, tight-tailored types. The idea being that things don't work are impossible to represent in the type system you have available. For example, say you have a gun that has the components "shoot bullets" and "hold bullets". If they are two separate components, there's ...


8

All bad code since the dawn of time has a story behind its evolution that makes it look reasonable step by step. Yours is no exception. Coders learn by coding. There are aspects of your problem you could not have foreseen that seem obvious now. There are decisions you made that were entirely reasonable incrementally, but led your architecture in the ...


9

Having a god class like this is never desirable, as it does not only mean that your bullets are now monolithic objects, but the same goes for your procedural generation algorithm as well. The first step would have been to analyze, why exactly your AI did have so much trouble with dealing with the complexity of your pattern? Did you, by chance, tried to ...


2

In some cases this is definitely acceptable. However, I find it hard to believe there is no good solution using both procedural generation and your nice attached/component based behavior architecture. If all behaviors where just pulled into the bullet class there is no functional difference between the god object, and neat architectured version. What made it ...


73

When building real-world programs, there is often a trade-off between staying pragmatic on one hand, and staying 100% clean on the other. If staying clean prohibits you to ship your product in time, then you are better off with a little bit of duct-tape to get the d***d thing out of the door. Said that, your description sounds different - it sounds you are ...


25

Interesting question. I am a bit biased though due to my previous experiences, which prompts me to answer with No. Short answer: We never stop learning. When you hit a wall like that, it is a chance to improve your architectural/design skills, not an excuse to add code smells. The longer version is that I have been asked similar questions a lot of times in ...


2

You're almost there... Putting the REST between the view and the controller would be the right choice. That means that your view, i.e. a javascript code, will send REST calls to your server, which process those calls in the appropriate controller (then the models and etc.). In addition this controller would be responsible for the response back to the ...


12

Your concerns are extremely valid. Especially the first two points about Team A not having the time to add features or fix bugs that impact Team B. I've seen this happen at my own job quite a few times. This might be a good idea if: It is known that Team A will be working on the projects that require new features in the database, while Team B's goal is ...


2

What you are looking for is the concept of a ViewModel. This is an object that contains only data that the view is interested in, and is very often not a 1 to 1 mapping with a business or domain model. It may be a cut down version of a business model, it may be an amalgamation of multiple different business models. If your view needs a count, this can ...


0

How about decoupling the user model from the task model. Instead create a TaskManager object that could get the tasks for the user. Something like TaskManager.getUserTasks(user); //which would return a list of Task objects the advantage of keeping these two is that you can keep on adding functionality without having to change the User model.


3

I would avoid bidirectional relationships as much as possible, as they can lead to synchronization problems (Child can end up having an obsolete ParentId). That being said, a unidirectional reference to another object by its ID only can be very useful. It's a very natural way of cutting an object graph in slices that can be loaded in memory from the ...


1

Keys are used to inform relationships and enforce referential integrity. Whether you need the ParentId key to live in the Child object depends on whether you will find yourself in a situation where you are working with a Child object and you need to know its parent. In general, I would suggest that it is good practice to include the key in the Child object ...


0

The default approach should be three "layers" or modules (Data Access, Business, UI). If you have any less, or any more, you better have a darn good reason IMO as three layers is the best solution for 90%+ of enterprise projects. More layers means fixes and changes take more time. Less layers can cause confusion and resistance to change as well. Why I used ...


4

What advantages do people see in using immutable request/response objects? I agree with @MainMa's statement "I'm not sure if the slight benefit of readability compensates the possible lack of flexibility" and personally I don't see any practical and useful aspects of forcing PHP HTTP Request temporary objects or PHP HTTP Response temporary objects to be ...


0

For a 3-tier architecture you are (partly) trying to scale. This means that you will offload some of the processing from the single database to a few application servers, and offload processing from them to many web servers. This also allows you to write code for each tier that is specialised, so the DB server will only run the DB, the app servers will only ...



Top 50 recent answers are included