New answers tagged

2

I think this depends on whether (A) your structure is small enough to easily fit in memory, and (B) whether you need to support lots of different parts being edited at once by different people. With that in mind, I think the simplest solution is to treat the relation-web as a single big unit (an "aggregate root"). It is responsible for recording ...


0

Yes you can do. Is it the right way : If you are thinking of single page mentality you should consider using lazy loading for images and if possible data. Alternatively you can create dom elements dynamicly so first load and render of page will be quicker. But it will make user wait for a few miliseconds for each data transfer. Another way is to use js ...


2

This is the approach which is used by many web applications. Should you do it? It depends. The full-AJAX approach has its drawbacks: SEO. For an interactive application which handles user content, such as GMail or Slack, or any other content which is not text, images or video, such as Google Maps, this is a non-issue: there is nothing to index. For ...


1

Your Business Layer is the place where the encryption should happen. Repositories should only concern with data retrieval and storage.


1

Does implementing hashing that difficult in the language/framework you use, so that it would justify a separate dedicated service? What I mean is that, for instance, in Python, it's just three lines of code. In C#, it looks much more complicated, but still not enough in my opinion to have a separate service for that. One interface, one implementation class, ...


1

Repositories generally shouldn't be involved in encryption unless it's a feature of the persistence-layer, so unless you're asking the database to do encryption/hashing or using some very interesting queries, I'd use a separate service. It splits up responsibility. Create a service, and if necessary you inject the Service into the Repository as a ...


1

I think you should be able to get/store these information in the details of the Spring Security Authentication (see org.springframework.security.core.Authentication#getDetails()). You should be able to access it through the SecurityContextHolder. If you want to add further information to the context you might want look at ...


1

Many discussions on this subject on StackOverflow are against your approach. I forward you, for instance, to this answer as well as to the post it linked to. However, your approach is the right thing to do for the simple reason that it reduces the attack surface area; and I may be it is a good idea to quote you this this real world example to highlight the ...


1

I'd suggest moving all your logging out of the presentation layer and move it into the service layer. That way, if another application wants to create entities, you don't lose the logging information. You could have a createNewEntity() method that simply logs the creation event and passes back an empty entity, keep your save() method, and also handle the ...


2

Using a thread local variable. I could store the IP address in the Controller into a thread local variable and access it in the EventService. I'm leaning towards this one, but I don't know. I've used this approach before, for storing contextual information about requests. I would perhaps expand from the above to store a thread-local request context ...


1

a very simple That would probably take DDD off the table. If you aren't anticipating a rich and subtle domain model, then you are likely past the point of diminishing returns. Why can't I just build a CRUD app If you are asking this question, it's another hint that DDD may not be the right horse. But taking it straight -- the problem with a CRUD ...


0

You may want to look at architecture documentation techniques. I think the arc 42 template might be interesting for you: http://confluence.arc42.org/display/LANDINGZON/landing+zone This related WIP guide might also be interesting for you: http://aim42.github.io/


2

You could send a signed payload with timestamp (in addition to question id, client id etc.) to the client together with the question. When answering the question the client has to send back the signed payload. The server can then verify the answer without holding any state regarding when the question was send to the client. The client itself provides the ...


3

I don't know if there is a more elegant solution, but it will probably come down to persisting the question timeout and asking the database whether the value is still valid and having the client to do the time's up logic. The first option, obviously, is to just have a client verification, where a user choses to answer a question, queries the server and gets ...


0

We ended up implementing the "Windows Service" scenario knowing that it would not scale but intending to build a scalable solution when we have to. With the current implementation a Web Job runs a console application that queries the DB for all notification definitions, runs appropriate queries and sends e-mails. It is easy to test (just run the console app) ...


1

Let's just assume for a minute that it is perfectly fine to skip DI with sknny controllers. Now what about the rest of your application? Dependency Injection as a technique is proven to be immensely useful and valuable. As others have noted, it encourages a more decoupled design which improves testability. These are extremely valuable perks! MVC or no ...


3

Dependency injection is often recommended in MVC projects because it's easy to implement with the pattern and adds a host of potential benefits I would argue that dependency injection is recommended generally in projects (not just MVC) because of the benefits it brings in terms of decoupling and testability. There's nothing specific to an MVC ...


1

Yes there is value because it allows you to unit test your controllers. The business layer and model should know nothing about http so the job of the controller is translating the business layer to a web world. Example: Exception Y was thrown should result in http status 4xx Precondition A was not met. Redirect to Abc So even if the controller is ...


0

Once you have a rough idea of what a class or function should do, you have enough information to write tests. These tests may fail, due to the thing you're testing being broken, but that is essentially a good thing. If you prefer writing the code before you write the tests for the code (sometimes, having an implementation may yield a better idea of what ...


4

You should be creating tests for all the code that you write, regardless of whether they're libraries or your application. Why ? you can assert that the code you write works the tests assert that that code continues to work as you change or add subsequent code. In short, it doesn't matter whether it's a library or an application that you're writing code ...


1

I think it's largely correct, other than I don't understand at the moment what part your delegate plays. As such I would probably remove it if you don't see that it adds anything. You can always add this in later. When faced with these issues, I try to keep some basic separation along the tracks of a well-known pattern e.g. MVC. My primary focus is to not ...


2

Shell, script, or application there are two different classifications here: Interactive and non-interactive An interactive shell reads commands from user input A shell running a script is always a non-interactive shell. All the same, the script can still access its tty. It is even possible to emulate an interactive shell in a script. ... ...


4

Non-interactive command Interactive command REPL Windowed / screen application I don't have a source for that; just years of hearing them called the same way. I'll see if I can find an authoritative source.


0

You are doing well at having controller layer away from repositories. Controllers doesn't have any idea about the business nor the way data is persisted. Let business layer deal with DAOs (repositories). That's a good practice. Despite it takes extra work to implement. Build up a service layer where every service get rid of its own business. Slug / ...


0

Admittedly, the DDD book doesn't make it very clear, but when it says "stateless" it means "without persistent or long-lived state". So, service objects are allowed to keep state in their instance variables/fields, as long as it's not state that gets persisted or externalized in some way. The state the book cares about, when discussing statefullness, is the ...


1

I think the root of your problem is that you are not using compositional patterns correctly. Instead of changing the model of these items, create a NEW model, which contains these items. That way the original identity and composition of these items are preserved. This article gives a fairly balanced look at the problem (even though it is targeting ...


1

It doesn't look like you need a "nearly accurate count" - you say you need to know that there are at least 25 objects in a state. To achieve this, you can for example have one method that counts the objects in that state, and possibly stops counting once it reaches 1,000 for example, and decrease the counter every time you move an object away from the ...


0

You make me feel old :-) IBM MQSeries was originally launched in 1992, and was primarily used on mainframe based systems. Java 1.0 was not released until 1996. I promise you that your application is not too old to talk to messaging systems. It may be that they don't wish to couple to a messaging system, but there is no way it is "too old". I have ...


0

These are not peripheral, these are standard use cases. They have ports/layers/etc that talk to the actual device controllers. https://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html actually calls this out fairly well. The device APIs are no different from a Database API. You call it the same way, encapsulating it just like you would ...


1

We had a similar problem with millions of rows per day. I will give an example with just one table and can be done similarly for others. Say the table was orders. orders would have the data for current table. It was always archived on a saturday and the data would be moved to a weekly table e.g orders_20160409 would have orders data for the week of April 9 ...


1

Another approach might be to have a Semesters table. Your core tables that are in use now would take a SemesterID as a foreign key. Put the Active bit on the Semesters table (or query it by datetime comparison, but I'd probably go with the archive bit). From there, you manage only the Semesters archive bit, and either: Inner Join to "active semesters" ...


1

This solution is certainly an acceptable solution, looking at your constraints, and the relatively small size of the database after 10 years. However, the frequency of your archiving shows that the data is inherently time dependent. I'd really put the year and semester or date of validity part of the data. This would avoid the necessity to archive, and ...


1

For any parameter for which your application has to interpret the semantics, your option 1 is IMHO the better one since it is simpler, more expressive and the additional flexibility of your option 2 does not bring you a benefit, since when you later introduce new, additional parameters you would need to change your application either. If some of the services ...


4

Business Domain refers to real-world aspects of your solution (e.g. Healthcare, Aviation, Finance, Military, Retail, etc). The business domain informs your requirements and acceptance criteria for the system; it can be suggestive of a very high-level form of segregation for different areas. For example, if you happen to be building a solution for a ...


2

Over the last 20 years I've seen a few large modular database designs and I've seen the scenario suggested by David quite a few times now where applications have write access to their own schema/set of tables and read access to another schema/set of tables. Most often this data that an application/module gets read-only access to could be described as "master ...


0

A useful starting point may be to reverse-engineer the code into a UML modelling tool of your choice. This will at least give you some diagrams showing the classes you have, and all their methods. But be aware that auto-generated UML diagrams tend to be very messy. All the classes from one package will end up on one diagram. The tool will have no idea ...


1

Since this is a hardware device, I would not worry too much about being able to dynamically add or remove channels, rather I would keep it simple stupid. As a consumer of the device interface i would better off accessing it like this, var device = //initialize the device device.In1.Write(dataIn1); device.In2.Write(dataIn2); var out = device.Out1.Read(); ...


3

I believe you should keep the amount of channels abstracted: The amount of channels may vary in the future, e.g. hardware up/downgrade (new devices) You may want to reserve some channels in the future, e.g. for out-of-band communications and notifications The exactness should be kept and ensured in initialization. You should expose the channels with the ...


2

Make sure you have some sort of context (for want of a better word) on all internal calls. This should contain an authentication token from the originator of any given request and can simply be passed on whenever you do internal requests. You then need to perform authorization, based on the authentication token (ideally by verifying the token EVERY time), ...


1

The best thing to do is to ensure that all requests are from an authenticated source. This could mean a user request, but also a 'service' user that corresponds to each microservice. If a hacker gains access to your tier2, and you have an un-authenticated API, they can wreak havoc. Each microservice should have its own distinct user for use for unsolicited ...



Top 50 recent answers are included