Tag Info

New answers tagged

0

Event storage Event storage will depend on your application but it is a lot easier if you use a flexible storage for your events (so a NoSQL DB, JSON or XML). How you deal with updates will depend on several factors you need to take into account such as requirements for availability and timeframes for updates, amount of events, etc... Update your events ...


1

Am I going about this the right way? Or am I maybe over-complicating it or missing something? I think you have a start of a design; you are teasing out the concepts and their basic relationships and the constraints on the relationships, which is a great start. For me, what I like to do is before I do any real detail on classes and operations (e.g. what ...


0

It depends on your concrete repositories, but generally speaking, I would add a service layer on top of the repositories. Depending on your repository implementation, they might be specific to your persistence store. It makes testing easier as well and leads to a hexagonal architecture, instead of a classic layered architecture (which I consider a benefit), ...


1

Yes, the service layer is an overhead if you don't have any business logic there. Layered architecture looks like an overhead when a layer (in your case service) is not doing much. But a layered architecture provides your loose coupling which is generally good for adapting requirements in future. If you can guarantee that you will never need to do anything ...


1

To complete Doc's response, events are not meant to return values, this would be a violation of the CQS pattern (separation of commands and queries, aka read/write). They capture business intentions, creating a kind of audit trail for all that happen in the system. They can be the only data source in the system. In that case, there may be no need to have a ...


2

Those two things do not much have in common, except the fact that also in the Service Layer pattern some kind of "events" may be involved. But that is where commonalities end. in the "Service Layer pattern", there are different layers calling each other and triggering some system change. But the calls are not necessarily "captured in event objects", nor ...


0

There are many considerations around class design, intelectual control, cohesion, future extensibility of the application, etc. My reccomendation on class size is focus on good functional cohesion and let the class size be what is natural. But, consider this variation on option B( or A?): you have broken down your business logic in to discreet functions ...


0

I'm against having large classes, even if all the methods are related, it makes more difficult to understand the code. So I vote for the [B] approach, where you pass the parameters to the constructor and the class implements an interface. This way, you can treat all classes as if they were of one type (interface type). You can handle the business logic ...


0

Did you look at role-based permissions? One controller, one route, returns/accepts different results depending on a user role. E.g. a GET request to http://blah.com/tickets will return all tickets if requester is an admin, or user's own tickets otherwise. A post to this route will return 200 for user, but 40x error (405 would fit here, I think?) for ...


1

It really depends on the context in which you want to invoke those functions. [A] assumes that the arguments of your method are always well known in the section of code you wish to invoke it. You should use a static method for these types of stateless calculations. [B] assumes that the arguments/state of the code is different depending on some other ...


0

If you are concerned about the ability of your system to scale as usage increases, here are a few things to think about. If activity is likely to come in bursts, you probably should give some thought to managing that, e.g. with a queue as another poster suggests. If you can smooth out the load by deferring incoming requests when the server is busy, you can ...


0

Since the providers for the sources of your data may not appreciate the load if you become successful and may block API access or wish to charge more for it, you may want to think about development of a proxy backend that caches the data where possible such that your server is buffering the data sources from an overload of requests. Incoming requests could ...


0

Your problem sounds like it is caused by a failure to follow the Interface Segregation Principle. Fortunately, there's a fairly simple solution: take your entity objects and create one interface in each for each type of client, containing only the methods that make sense for that client. Then, for each client, create a wrapper for your ORM that works using ...


1

It looks like you want to spool the result of HTTP requests. Indeed, you might use some caching HTTP proxy like squid (you might use it, instead of coding your own). You could use both HTTP client libraries (like libcurl) and HTTP server libraries (like libonion) in the same process (but probably in different threads, or thru some event loop like libev or ...


5

I don't think you should have syntax highlighting information directly in your text buffer. Instead, I would add additional data structures for the display code. Here's why: Once you're providing functionality like selections etc, you'll probably need an anchor concept (a steady pointer to a specific location in the buffer, even when characters are ...


0

Its good practice to expose only the options a user is authorized for. This forces authorization to be a cross cutting concern. The "View" needs to know what a user is allowed to do before it can build options and menus for display. The back end should not trust the front end to make security decisions so must check authorization itself. There may be ...


0

Your design seems that it can benefit from Asynchronous Messaging Messages can be sent through different pipelines to multiple receiving applications and scheduled for execution at certain time (the scheduling can be a built-in feature of the message bus (middle-ware) or can be baked in your solution (reply with with a shceudled task id message and send the ...


2

I fully support pushing authorization checks down as low as they can go! And in doing so, you're not prohibited from writing automated authorization tests against every layer "above" it -- which I'd encourage if it soothes a paranoid feeling, allows you to enforce more strict rules at the service layer (CanView/CanSerialize?), or introduces edge cases like ...


0

You can use Gradle build flavors to create two APK files from the same code base. The two APK files would have different package name. Different package name means they can be installed on the same phone side by side & they will have different local databases. productFlavors { vanilla { packageName "com.example.myapp" } strawberry ...


2

In the business layer you simply don't honor any update even if it does come from the UI. I guess you could also do this in the data layer but that does not mean skip it in the business layer. For that matter you could also enforce it a the database with for example triggers. In the business layer you expose a flag / property of IsEditable (or some other ...


0

As suggested in at least one of the answers here but also elsewhere on the web, it is possible to design one microservice which persists entities together within a normal transaction if you need consistency between the two entities. But at the same time, you might well have the situation where the entities really do not belong in the same microservice, ...


0

Do both If you are making a framework, flexibility is key. Most frameworks provide interfaces and default implementations along with empty constructors wired to defaults, but allow for you to overwrite behavior by passing in your own implementations, or passing in a framework-provided alternative implementation. public interface IReader { string Read(); } ...


-1

I wrote a pretty neat query object pattern for NHibernate here: https://github.com/shaynevanasperen/NHibernate.Sessions.Operations It works by using an interface like this: public interface IDatabases { ISessionManager SessionManager { get; } T Query<T>(IDatabaseQuery<T> query); T Query<T>(ICachedDatabaseQuery<T> ...


-3

I'm building an app in C# that needs a fixed-length id, which is a string representation of a hex number. So use a string. Anything else is a waste of time. On the day you find that you somehow passed an ID code string of the wrong length, add an extension method to check the string length.


1

Your code is much too complicated for such a simple requirement. This is because you are focusing on the representation (four hex characters) when you should be focusing on the thing represented, which is merely a two-byte integer. A C# ushort is precisely that type. For convenience, you could create a struct (not a class) that contains a short and methods ...


0

It is not quite clear, what you want. at the Login I recive the User Object from the Server An user has a List of tasks, but I don't want to load them at the Login So what would be an good style to recive the Tasks of an user If I understand that correctly, the list of tasks could be long, so receving the list of task would be something which ...


1

The second approach seems more clean, however if I need a new length for the ids I would have to make a new class AND replace the instance of the old class everywhere it is used You already gave the two striking arguments why this is exact the opposite of beeing clean. So you should avoid specific derivations for specific lengths. However, you wrote ...


0

My understanding of CQRS here, is it definitely feels like a disciplined implementation strategy for the middle tier more specifically (*) itself a supplier of the service tier (which calls into CQRS) - e.g., WCF, and a consumer of the domain model/data tiers (which is called from CQRS) - e.g., ADO.NET, Entity Framework, or whatnot. So, unless I missed ...


0

As @Machado said, the easiest way to do it is to avoid it and doing all your processing in your main java. However, it is still possible to have to code base with similar code without repeating your self by generating the code for both of code base. For example using cog enable to generate the three snippets from a common definition snippet 1: /*[[[cog ...


1

tl;dr Your decisions on how much to abstract should be dependent upon your business problem to choose how much of the baby to split. Understanding relationships and how to define them properly without creating 'god' objects is a common problem when architecting solutions. Your idea on compromise is spot on when you are trying to accomplish something and ...


0

I think we've learned a lot since SRP was introduced, but in a more indirect and general way due to the changes in the way software development projects are managed. SRP is a principle that wasn't intended to have a set of strict rules that could be blindly applied to all situations. It depends. There are some general rules that experience has taught us that ...


2

Consider two options. Validate everything on the server, at all times. Suppose you pay for 2 extra weeks of developer time (e.g. $10k), and e.g. $100/mo extra for more computing power. Nothing interesting happens. Do not validate input and save the money and time. Then someone mischievous steals a secret, finds out that the server side allows to do ...


2

I'd say no, its not. The reason is that anyone can sniff the network traffic to see what your calls are, and if you're not validating, you're opening up security risks as well as data corruption risks. The performance rationalization doesn't hold water; are there performance issues on the client running the rules? If not, then there should not be ...


0

As you pointed out, it's best to do validation both client side and server side. You want the client side validation so you can quickly give feedback to the user, and you want it server side because often the people who write the server code aren't the same people who write the client code and it's necessary to check assumptions. However, the code has been ...


1

Your approach is far different from that of most PHP applications does, obviously a template engine binds some logic in views, most programmers prefer writing this logic in PHP itself. Limiting PHP to create services/ API s to only manipulate Data is a good idea, indeed. You may consider http://backbonejs.org/. I believe you could use it to write all ...



Top 50 recent answers are included