Tag Info

New answers tagged

1

If each user truly has their own products, and user Joe's product named 'Foo' has nothing to do with user Jane'e product named 'Foo' (too, by pure coincidence), then the user ID does belong to your problem domain. I don't see why you have to add a user ID column to every table that references a product. A product may have an (artificial) unique PK, and a ...


2

However, that only makes sense if I create a different class for each different element, which doesn't seem right To me, this feels perfectly right, since, it is just an application of the classic "strategy" pattern (in this case a RoundScoreCalculationStrategy). I would design this in a way like this: interface RoundScoreCalculationStrategy { ...


0

The controller is for application logic; logic which is specific to how your application wants to interact with the domain of knowledge it pertains to. The model is for logic that is independent of the application. i.e. logic that is valid in all possible applications of the domain of knowledge it pertains to. Hence nearly all business rules will be in the ...


0

I like DougM's answer about how to handle in Java (a string for the user who last updated the table record). The goal here is to manage this inside your app. However, I don't think we have enough information here on the full-breadth of tracking updates in this system especially from the database perspective. Are you going to guarantee all changes to records ...


0

This code feels like overkill, but it doesn't feel right to have everything public so that anything can change an objects location for example. Encapsulation is part of the problem, but I'd argue that you should design objects with services to clients (responsibilities) which are more abstract than simple methods (sets and gets). setLocation(x,y) is ...


0

The idea is to restrict what objects can modify another object. There are two broad ways to achieve this. Forget it and let anyone modify the objects. Just do not call the mutating functions from outside Level and move on. Use a language feature to achieve this. For example, in C++ you could use the friend keyword to allow Level more access. In Java, you ...


0

A simple solution would be to make them immutable and produce new world objects for the next world state. This gives the Level complete control over the world's state without allowing objects to interfere with each other directly. Another benefit of this approach is that it still works even if your world objects stop being pure data and have some internal ...


0

Both are possible, but the question is why would you want to use one over another. First case allows you to do additional work when setting flags. Maybe you want to modify something else or notify other piece of code. This is especially true for aggregate roots, whose reason for existence is primarily to ensure business rules over multiple entities. But ...


0

You're placing too much responsibility into the Repository here, drifting away from the original pattern. A Repository is just supposed to be a conceptual set of domain objects, a collection you can query from or add to without minding about the underlying persistent storage. modifyFlags(EntityId $id, EntityFlags $flags) could typically be the signature of ...


-1

First, you define the constructor as "package private" by omitting the access modifier. This makes it so that the constructor can be called from same package, but not from package that is using your package. Then you create a static method that creates and returns the concrete instance. This will have same code as you have written.


3

It's called a Factory Method. You just have to make it static, so that you can call it on a class, rather than an instantiated object. public static Player generate_player() { elder_tales.Player p = new ...whatever p.set_stats(); p.set_server(); p.calculate_experience(); return p; } This method goes in your Player class, or whatever ...


0

To work with entities, you really should be using either Linq-to-SQL, or Entity Framework. There other ORMs but few are really worth it, they have nothing real to offer over EF6. To do this, you first create a model (or multiple models) of your datasources, and then use that model to query the data source through Linq queries. The ORM acts as an abstraction ...


2

I would have QA test them. Seriously: if QA is able to read a use case and understand the program flow without a priori knowledge of the code (which tends to make a developer biased in terms of testing anything) then it is likely at least decent quality. When it comes to validating requirements, use cases, and other documentation that typically comes near ...


0

The most interesting concept to follow here is a Single Responsibility Principal. It does mean you need a dedicated classes for each aspect/behaviour/state. I would go with: public class Product { public string Descripion { get; set; } public Uri Thumbnail { get; set; } } ProductFormat -> to choose Short/Full/etc. public abstract class ...


0

I have some code that illustrates some of the differences wrt visibility and "default" implementations when extending vs setting a self-type. It does not illustrate any of the parts discussed already about how actual name collisions are resolved, but instead focuses on what is possible and not possible to do. trait A1 { self: B => def doit { ...


0

I agree completely with Chao's answer and so I will not repeat that. I think that the real problem here is that you need to ask yourself some more fundamental questions about the problem domain. Remember that all code is written to solve a problem. Why are we writing a base Documentclass in the first place? Why are we deriving from the Document class? ...


1

From what I understand your question to be, it seems like your Data Access Layer classes were accessing the Common Assembly and then your Business Layer accessed your Project Specific Data Access Layer. Now you want to put some of your Common Data Access layer classes into the Common Assembly. You think it is no longer OK for the Business Layer to access ...


2

This exact problem is why Dependency Inversion Principle exists. This principle says. High-level modules should not depend on low-level modules. Both should depend on abstractions. Abstractions should not depend on details. Details should depend on abstractions. In your case, the business layer depends on detail that is data access. To fix this you ...


3

Consider using delegates instead of abstract classes. The Template Method pattern is mostly a hack to work around a language's lack of first-class functions. So instead of overriding "execute", pass it in as an argument. That aside, why don't you want dependencies between assemblies? What good is your Common assembly if you're not going to use it?


1

Since what you're doing is write a custom binary protocol for performing cross-language RPCs, it makes sense to have separate IDs for the components and their commands. For example: a fixed number of bytes in the beginning of the byte array could be used to specify the component, while the following bytes (another fixed number) would represent the ...


0

The most modular way is to let each receiving module register itself with the main command handler for receiving the commands that it can handle. Assuming that there is at most one handler for each command, you would get something like this (pseudo code) class MainCommandHandler { public: RegisterCommandHandler(CommandID, ICommandHandler*); ...


0

Use Facade (or possibly Adapter) to create your own internal interface into the message system, and wrap it around & hide the external message classes. http://en.wikipedia.org/wiki/Facade_pattern At test time, this makes it easy to stub or mock, because you only have to make fakes for your facade. At run time, the facade can interact with the real, ...


1

Other answers are correct. One additional thought… Business Logic Is Portable If you were to re-implement a software project in a different programming language, say moving from Turbo Pascal to Java, business logic & business rules is what the old and new projects would have in common. The programming language would be different. The source code ...


4

Business logic or rules are anything that don't pertain to the mechanics of the user interface (the "programming stuff"). They are the things you would still have to apply if you were doing this transaction or whatever 100 years ago (manually). For example, when to apply sales tax to a purchase.


2

It should provide neither a straight CRUD interface nor do business logic. It mediates between business logic and the database. The interface should be in business logic terms but not perform business logic itself, more like a business logic primitive. As an example say you were going to build an email system, you have users and messages. Your Repository ...


2

Well, you can see a good example in the Spring Data Framework which is based on the concept of repositories. There you will see repositories only deal with the data store, and rarely contain any business logic (this is reserved for the service layer). So, for instance, you take a look a their design you will see they have a CRUDRepository interface which ...


6

Business logic basically consists of 2 broad categories: validation and flow. Business logic says that qty 1 must be greater than or equal to qty 2 -- for example, number of items to purchase must be less than or equal to number of items in stock. In one application, the business folks will say this is a business rule, and so you write code to enforce ...


1

The "business logic" of a program or application is the part of the code that actually does things with input (from the user, the operating system, and etc). The "business rules" of an application is usually the defined parameters of the program itself (such as how to handle input). At least, this is how I have heard it referred to from many people. They ...


49

CRUD is an acronym that stands for Create, Read, Update and Delete. Those are the four basic operations that you can perform on a database tuple. But there's always more to business applications than creating, reading, updating and deleting database records. Let's start with some basic definitions, and then look at a couple of examples and see how those ...


13

CRUD is simply the Create, Read, Update, Delete that an application does. To an extent, a bug tracker is a CRUD app too. Create bugs, Read (display) the bugs, Update the bugs, and maybe, delete them. However, there is more to a bug tracker than just CRUD. A developer isn't allowed to mark the bug verified or closed - thats part of QA's job. And so some ...


1

I think your best bet is to design the system as a state machine. The idea is that you have objects symbolizing each discrete step of the process, including any state data that has accumulated so far, and by pointing to the subtask currently being executed you can reconstruct the execution from that point. However, I've just remembered that there is a C# ...


1

what could be the User object Behavior ? I cannt find any ! login, its an auth lib. thing so i should not include it in user. posting articles is a Post object thing; again user conduct it; but its more of a post object concern to create a post right ? User may be the main Aggregate object in a blog; yet the user is more like the Creator of ...



Top 50 recent answers are included