Tag Info

Hot answers tagged

45

Surprisingly, I don't see in the other answers what i consider the real difference between REST and CRUD: what does each one manages. CRUD means the basic operations to be done in a data repository. You directly handle records or data objects; apart from these operations, the records are passive entities. Typically it's just database tables and records. ...


38

First of all, both are simply common initials; they're nothing to be afraid of. Now, CRUD is a simple term that was abbreviated because it's a common feature in many applications, and it's easier to say CRUD. It describes the 4 basic operations you can perform on data (or a resource). Create, Read, Update, Delete. REST however, is a named practice (just ...


19

Is it possible to achieve having a view with no business logic at all? I find this a deceptively hard question to answer. (Thought-provoking question!) Theoretically, yes, depending on what we define as business logic. In practice, strict separation becomes a lot harder, and maybe even undesirable. Separation of concerns is a great way to think ...


14

Marking a record as deleted is known as soft-deleting. I've never heard an alternate phrase for updating, but I guess that's cause you soft-delete the old record and create a new one. It should be noted, this is a controversial technique. See links: Con vs Pro.


9

One of the problems with retaining a change history is that it clutters up the database and can dramatically increase its size (depending on usage patterns). So a good idea would be to store the audit trail in a separate place, and keep the actual application tables populated only with relevant data. So each time a CRUD operation is performed by the ...


8

I usually do this: if the user has selected option x, the view calls controller->OptionXChanged() Then controller enable y on the view: view->SetEnableInfoY(True) // suppose False=SetDisable The view notifies the controller of what happens without deciding anything.


6

The proper way to handle this is to lock the object when the first user starts editing it, and have the application check for locks on an object before deleting it. For example, you could have a tasks_locks table that looks like this: task_locks ---------- task_id user_id lock_timestamp When a user goes to edit a task, the application should ...


4

EventSourcing sounds like the pattern that you may be looking for. Let's take an example using a simple "car" object that we would want to keep track of the color of (pseudo C# code follows). public class Car { public string Color { get; set; } public Car() { this.Color = "Blue"; } } With a CRUD implementation when we update the color of the car the ...


4

I question whether the examples you describe are really business logic. The examples you describe are operations that can be performed on the system. It is how you chose to present the choices to the user that maybe gives the appearance that you are doing business logic in the view. From the "View" vantage point it is only providing InfoY or InfoZ to the ...


3

Event Sourcing is the way to go, and you should take a look at what Greg Young has to say about that. http://goodenoughsoftware.net/ Also take a look at this presentation on his Database (Event Store). You can find other videos as well. http://oredev.org/2012/sessions/a-deep-look-into-the-event-store I wouldn't go for the "soft-deletes" answer unless you ...


3

REST stands for "representational state transfer", which means it's all about communicating and modifying the state of some resource in a system. REST gets quite involved, because the theory behind REST gets into leveraging media, hypermedia, and an underlying protocol to manage information on a remote system. CRUD, on the other hand, is a mnemonic for the ...


2

CRUD specifies a minimal set of basic storage verbs for data reading and writing: create, read, update and delete. Then, you can build other operations by aggregating these. These are usually considered database operations, but what is considered a database is arbitrary (e.g., could be a relational DBMS, but could also be YAML files). REST is an ...


2

It seems that what you've described (i.e. Employee class having ALL possible code that you could do with an employee) is an extremely common pattern that I've personally seen quite a lot. Some of that code I've written myself before I knew any better. What starts off as a class that is supposed to represent a single entity with manageable set of methods, ...


2

After a lot of searching around the net as much as I could here's the end results I've come up with based on my research. Things to avoid Avoid using void with async methods. Voids don't pass exceptions up to the calling method which can lead to hard to debug async code. (this can be mitigated, but is still discouraged) Avoid using Booleans with ...


1

In most cases there will be problems like "If the user has selected option x then the application must enable him to supply info for y, if not then s/he should supply info z" That is logic for the model, not the view. It may be a "view-model", created specifically to support the UI, but it is still model logic. The control sequence is: Controller ...


1

I work this way (Struts2 + Hibernate): My Struts Actions is only responsible for show informations on web browser. Not thinking. User -> Action -> Service -> Repository -> Data Access Or: I Want See -> How to see -> What to Do -> How to Get -> Where to get So, in first layer (the view) I have something like: public String execute () { try { ...


1

Yes its quite common in enterprise systems there are basically two approaches:- "bi - temporal" in which every record has a valid from and valid to time stamp (the "current" record having a valid to date of "forever" - null, "9999-12-31" or some such high value). Records are never deleted instead the "valid to" date is set to the current time and in the ...


1

Not precisely your example, but in older financial systems you had WORM storage. If you needed to "update" you wrote a new record and you always referred to the last record as current but no committed data could ever be overwritten. A lot of folks carried that idea over into later systems. I have heard what you are describing referred to as WORM tables, ...


1

You can use "soft-deletes" as pdr suggested. As for updates, you could keep history of records, sort of like my answer here: http://dba.stackexchange.com/questions/28195/save-history-editable-data-rdbms/28201#28201 where the OP wanted to be able to keep track of all versions of certain kinds of data.


1

Interesting, Im developing a similar system for oil & gas, with Google Maps API v3. We chose to use CouchDB for the part of your diagram that includes GIS data, central repository, and other data sources. The idea behind this is one container to hold disparate sources of data with different types of structure, and also actual data files that represent ...


1

Maintaining an Audit table of denormalized DomainObject records with various user actions is the best bet. By flattening the object tree of DomainObject and storing all the data in an Audit table with user information and timestamps, then you have a complete history of all changes to DomainObject's regardless of Create, Update or Delete operations. By ...


1

There is a new requirement: keep track of the s that have been created since the app was opened, so that the user can see what he/she has done. I Don't fully understand you three ways But the correct way to do this is as follows. Every table in your system (The you want yo track) should have the following four fields on them: CreateDateTime ...



Only top voted, non community-wiki answers of a minimum length are eligible