I heard the terms Data Driven and Event Driven model from different folks in past. I did google but these terms are still vague to me as both
of them looks similar to me
Data driven programming is a programming model where the data itself controls the flow of the program ( not the program logic) where in case of Event driven programming ,
it is the event not the data itself controls the flow of the program.
Per mine understanding event is also the data . For example in employee based web application - If user clicks the create employee button, here event is create employee(which is also kind of data only) and data is employee related information.
Now at server first it will be event which will decide what will be flow of program and then data(employee related information) will also control the flow of execution like if permanent employee different method will be executed and if temporary it will be different
So is not every thing a data driven architecture ? If no what is the difference between them ? Any web based example will help
data itself controls the flow of the program ( not the program logic)
I guess you are not completely understand what is “flow” in this context. Flow is logic itself. For example, if you are executing some method that does A, then B, then C to it's arguments, logic would be “Apply A, B, C” and flow would be the same if actions A, B, C are extracted to separate methods. So, flow and logic are synonyms.
Data driven programming means that some general code exists. It does not contain any business logic, it does not control flow. It's just a tool to read and process data and output result. What controls flow and logic is data itself. So, if you want to change business logic (literally change result of your program), you change data, not code.
And your code is, well, it is a kind of pipeline that executes commands depending on input data. You can think of such code as of eval function in javascript.
In Event driven programming logic is controlled by events. And that means that data is only data, and all business rules are placed in code. Event would carry some data, and logic could be changed depending on event's data, but the difference here is where these changing logic rules are placed — in data or in code; and in case of EDP, the logic is in code.
Also, take a look at this question, some answers could shed some light on the subject.
The explanation above is very apt. To supplement the above answer, in Data Driven Architecture the business can feed in the logic directly in the data sheet thereby making it very easy to control the logic in the downstream components. Feeding is generally done using user friendly tools. Generally a product Master File is maintained which consists of the data variables and those are updated depending on the business requirement. It is so much easy for business to do this and a huge cost savings compared to event driven where every small change in business requirement resulted in huge cost to develop-test-deploy the piece of software.
Related
I am a data scientist, tasked with creating forms for user inputs to computations. These inputs include date ranges, integers, etc. Every computation describes its necessary and optional inputs. I would like to automatically turn a computation description into an HTML form, including (server side) validation of user entries. For a toy example, consider
Computation 1: Divide a by b
Description: Divide two integers!
a: int
b: int
Result: a/b
This should be turned into an HTML form asking for a, b, and the description. This form does not need to be pretty, but should look presentable. There are many graphical form building tools out there, is there also a tool allowing programmatic form building? Is there even an open source tool? Since I am not a frontend developer I would prefer to use such a tool instead of developing my own logic. I would also like to keep the validation logic on the server side (here: b!=0), necessitating the possibility to programmatically talk to the form in some way.
On a higher level, is this even the right way to go about creating UIs for computations defining their own inputs, with short computation times?
Thank you for any suggestions.
I'm using multiple atoms within a map called app-state and it's working quite well architecturally so far. The state distributed across those atoms is normalised, reflecting as it is stored in datomic, and of course what the client is initialised with is a specific subset of what's in datomic. This is me preparing the way to try out datascript (which is what gave me the aha moment of why client state is so much better fully normalised, even if not using datascript).
I have a question at this point. We all know that some state in reagent is a reflection of what's in the server's database (typically), but there's also state in reagent concerning solely the current condition of the ui. That state will vanish when the page is re-loaded and there's (typically) no need to store that on the server.
So, I'm looking at my list of atoms and realising that I have some atoms which hold database-record-like maps, i.e. they contain exact reflections of datomic entities, (which arrive by transit), which is great.
But now I notice I also want some ui state per datomic entity.
So the question arises whether to (this seems wrong to me) add some keys to what came from datomic, of the ui state that is irrelevant to datomic, but that the client needs (i.e., dump it into the same nested map). That is entirely possible, but seems wrong, and so suggests.... (this being my idea as of now), How about a parallel atom per "entity", like #<entity-name>-ui, containing a map (or even a vector of maps, if multiple entities), with a set of keys for ui state.
That seems an improvement on what I have ended up with by default as of now, which is separate atom for every piece of ui state (I've avoided component local state up to now). (Currently the ui only holds ui state for one record at a time, so these ui atoms need only be concerned with a single current entity).
But if, say, I made a parallel atom (to avoid mixing ephemeral ui and server state), then ui state could perhaps manageably extend deeper. We could hold, say, ui state per entity so switching current-entity back and forth would remember ui state.
Since this is Stack Overflow, I have to ask a specific question, rather than this just be discussion, so: given what I've described, what are some sensible architectural choices in this case, to store state in reagent?
If you are storing your app state in several component-independent reagent atoms already - you can check https://github.com/day8/re-frame which is a widely-adopted reagent-powered framework exactly for your case. Essentially it stores all the application state in a reagent atom but has a well-developed infrastructure to support coordinated storage and updates. They have brilliant documentation with a great high-level explanation of the idea.
Regarding your initial question about server/ui state separation - I think you should definitely go this way. It'll give you a better way of separating concerns and give you an easier way to update server/ui data separately. It is very easy to achieve this with re-frame by storing both parts of the state under separate top-level keys in re-frame application db. E.g.
{:server {:entity-name ...}
:ui {:entity-name ...}}
and then create suitable subscriptions(see re-frame docs) to retrieve it.
I have a pretty good project task management system going in Microsoft Access, but one feature I'm still missing is some type of 'quick entry' like facility often found in many good productivity applications.
This is how it would work:
Scenario 1:
You're in another application, working on a few things, and you just remember something that needs to get done. You hit your predefined shortcut: CTRL + ALT + T (again, from outside Microsoft Access) and it brings up a small access form with a text box in to which you can type what needs to get done, e.g.
Inform key stakeholders of concerns regarding timeline
you hit return and that gets saved as a record in Microsoft Access instantly.
An alternative, and slightly more complex scenario...
Scenario 2:
As above, but you want to add further details besides the task name, such as the person you need to speak to, and a due date. The input in to the text box could look like this:
Inform #Sally of concerns regarding timeline >+3
Where '#' tells access to populate a field called 'Contact' with 'Sally' (unless it already exists) and '>+3' is interpreted by access to mean a due date 3 days from today.
How difficult are Scenario 1 and Scenario 2 to perform? What level of VBA/programming knowledge would be required?
Thanks,
I would say it requires a fair amount of confidence in VBA.
You need to register a global hot-key; that is, a keyboard-combination that can be captured from outside the Access application. It requires win-api calls. Here is some code.
You need to know where to place these calls. I believe you have to put them in a standard module, not in the form's class module. (I haven't double-checked this, it's late.)
You need to have a little understanding about what this code is doing. NEVER attempt to type this api-code - copy it from a reliable source, exactly as it is!! You don't need to fully understand the code, but you need to know how (and when) to call each function.
Once you've registered the hot-key then your VBA needs to bring your application to the front and display your form, and focus it. Reliably bringing the application to the front may also require api-calls.
Once your form is opened (and focused) you can have a button on it to parse the information in its textbox. However, if you are designing the form anyway, I would add checkboxes, comboboxes, etc., rather than trying to parse a complex sentence/ statement.
This is more of a theoretical question rather than language specific, but I'm mostly referring to AS3.
Let's say I have an app that shows buttons through a couple of levels of navigation.
For example artistsAlphabetical->albums->songs or songsAlphabetical->song or albumsAlphabetical->album->song
so we'd set up a model(Data) with all the songs (the lowest common denominator - it would have the artist/album/year etc. info within the song object)
Let's say we don't have a dataset for the albums and need to extract that from songs. or we do have a datasaet and need to match them up.
Where should that fall under? Model or Controller?
I can find reasons for either, but am wondering what the "correcter" way would be.
Next we have the View with all the buttons to do the sorting.
When you click on the sort button Artists-A - that's the View sending a message to the Controller to do something (get alphabetical list of artists that start with A). The end result should be a new (paginated view if necessary) with buttons for each artist.
Which part of MVC should be responsible for each step?
Generating a list of artists that start with A
would it be the controller that says - 'Hey model - Artists that start with 'A' NOW!'
or, would it be more like 'Model - send me a list of all the Artists, I need to find the A-dawgs'?
essentially should the model do the sorting (and cache it if possible/needed) or should the logic be under the Controller, and the Model can store the cache?
So once we have a list of the artists, we need to create a button for all the ones that fit on the screen plus some previous/next buttons. Who should be creating the Buttons?
Should there be a View Controller? A Sub-Controller that only deals with the logic needed to create the views? Or would the logic be part of the View? It seems to me that the app's Controller would be all like 'not in my job description... I gave you the list you needed rest is up to you'
I feel like I'm conflicted between two views of MVC, one (mvC) - where the Controller is working like a motherlicker, and the Model is a glorified data holder and the view manages DisplayObjects. Or (an MVc) where the controller is the manager/delegator that makes sure that the Model and the View communicate properly, so that the model and view would have a fair amount of logic, and the controller would handle communication and delegate top level interaction.
While I am doing most of my stuff in AS3, I am curious how other languages would handle this. For example, in PHP Frameworks, you wouldn't need to worry about the button logic and event handling as much as with as3, where you need to watch Garbage collection, so the workload of one component there might be different than in a Cinder++, processing or actionscript app.
I don't know AS3. I do both Spring MVC/Java, which really lets you do either approach, and also Ruby on Rails, which favors smart models and dumb controllers. I like the smart model/dumb controller approach better.
So to me, anything to do with sorting and filtering the data should absolutely be done in the model, as should the process of extracting Albums from a list of Songs.
In Rails, I would put the process of creating the set of buttons in the view layer without question. If there's actual logic involved, that would go into a view helper method.
As you stated already, this comes down mostly to preference, but typically I would opt for the sorting to be done in the controller. I tend to keep my models purely about data storage and reduce the amount of functionality in them. So in your example, the model's job would be to hold all of the artists' data, and the controller's job would be to extract the artists starting with "A" from that data, and subsequently passing that sorted data to the view.
I don't use traditional MVC anymore, so I tend to think more in terms of PureMVC (proxies, mediators, and commands) now.
In general, I tend towards more functional proxies (think model) where the data gets abstracted (for the typical reasons for abstracting data). So, in your cases, there would be a MusicLibrary proxy, and would probably have methods like byArtist(), byTitle(), byRandom(), etc.
In a PureMVC app, a sequence for your scenario would look like:
Component catches mouse click and sends Mouse.CLICK
Mediator wrangling the component catches event, and sends notification SORTBY_ARTIST_CLICKED
Command which is requesting notification of SORTBY_ARTIST_CLICKED, calls the the byArtist() method on the proxy, builds a notification NEW_MUSIC_LIST w/ the data and sends it
Mediator requesting notification of NEW_MUSIC_LIST then does its thing and updates the components is is wrangling
I think this would align with what JacobM describes as smart model / dumb controller. I think that this approach leads better resuse, and also better isolates impact from chages.
I will say that in general, if I have different views of the same data (like in your case), I will use commands to push out the data, but if a view just gets a data update I will often have the view just pull the data from a proxy.
How many ways are there to learn implementing workflow of a software? What are them?
If you mean the user workflow, how the user is guided through the software...
I usually use some sort of state machine to limit what functionality can be triggered by the user and what information will be presented to the user in a particular state of the workflow. This way I can concentrate on designing each segment of the flow in its own "sandbox" and decision making becomes a lot easier.
If you do not mean user workflow, you can ignore this reply.
Usually you do have steps in workflow. Step consist of some precondition (business logic hidden from UI), some user interaction (user entering some data, and doing some “user stuff”), and post conditions. Usually user interaction part has one or more user chosen “exists”, and every exit consist it’s own post condition (usually every user exit has it’s own business logic depending of a meaning of an exit from a step). Exits navigate workflow to next step. Sometimes you can have fully automatic steps (i.e. using some external data source, calling some web service, important calculation, and so on).
If your workflow is simple, you may implement it as a set of classes representing each step, and configuration of steps order can be put in XML. When your workflow will grow bigger, and bigger, it may be reasonable to search for some workflow engine, (discussion of WF engines is I think beyond the scope of this question).
One important thing – steps can be orthogonal, but it is harder to design. If your steps rely one on another, person configuring workflow and steps order must be fully aware of such dependencies (e.g: user address step will probably depends on user object creation step, and removing user object creation step from a workflow, will result in trying to access nonexistent object).