Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
If I have a business object with 50 fields, and I need to populate something like a drop down list or gridview with only 3 fields from the business object to allow quick browsing.
Is it best practice to load the fully populated BO then just grab the few required fields in your presentation layer ?
It seems inefficient to populate a collection of Bo's that size but the only other ways would seem to be to return partially populated BO's with just the fields you need for a particular UI which would be hard to manage if you have alot of similar UI requirements, or make a baseclass like MyBusinessObjectHeader that contains the fields then make MyBusinessObject inherit it and implement the rest of the fields but this would tie it your UI too much it seems.
Whats the best practice for this type of situation ?
I make a separate readonly list of readonly digest objects (or structs) that are lightweight and cannot be manipulated. The collection can be customized for whatever needs you might have as normal. Retrieval of a full object can be used by passing a "digest" object to a type conversion, or factory or constructor - whatever techniques you are using.
Note that this is an optimization which only happens when a collection of full-blown objects is simply getting too slow. It can easily be created at that point. Generally such classes are not created until necessary.
There are a lot of frameworks out there that do this sort of o/r mapping you're talking about.
You're trading a little more overhead for ease of use and robust configuration.
See Hibernate or NHibernate if you're using .net.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I'm asking because I am not sure what kind of person we'll need to hire (ASP? Sitecore? Angular? JQuery) to implement the following for us:
Our school is looking to make data on courses (JSON format, about 600 courses) available as an “online catalog.” The static info (programs information, resources, etc.) will be hosted in Sitecore 7.
We’d like to see the online course catalog closely integrated with the rest of the site, so we’re looking for best approaches on how to do that.
Some manipulation of the JSON data is required: course detail pages should be simple enough, but we’ll also need to have course listings (not necessarily displaying all 600 courses at once, in one long list, but segmented by programs, class formats & locations, etc) as well as a “course search” functionality.
Would Sitecore do that well enough out-of-the-box, or would it be better/easier to go with something like Angular JS on top of Sitecore?
Please ask me for additional info if I had left something important out or if anything is unclear.
I agree with Dijkgraaf comment but to provide you with answer; Sitecore is suitable for your requirements but is a framework which means out of the box it won't meet your requirement so you will need a Developer who knows Sitecore and by extension .NET (Sitecore is built on .NET).
These developers will also know how to work with JSON, most likely serving it up from Sitecore via a .NET technology called Web API. The JSON can then be manipulated with Javascript or AngularJS. It is not as common for Sitecore developers to be familiar with AngularJS however.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
Why is JSON-formatted data stored in MongoDB? Is that the only format supported in MongoDB? What are the advantages of using JSON for storing records in MongoDB? What is the benefit of using JSON in Mong DB over other formats?
Actually Mongo uses BSON, that could represent the same things that JSON, but with less space. "JSON" (that is like the representation for human beings) have some properties useful in a NoSQL database:
No need for a fixed schema. You could just add whatever you want and it will be correct JSON.
There are parsers available for almost any programming language out there.
The format is programmer friendly, not like some alternatives... I'm looking at you, XML ¬¬.
Mongo needs to understand the data, without forcing a "collection schema". You don't need information about the object to reason about it, if it uses JSON. For example, you could get the "title" or "age" for any JSON document, just find that field. With other formats (eg. protocol buffers) thats not possible. At least without a lot of code...
(Added) Because Mongo is a database they want to do queries fast. BSON/JSON is a format that can meet that requirement AND the others at the same time (easily implementable, allow reflectioning about data, parsing speed, no fixed schema, etc).
(Added) Mongo reuses a Javascript engine for their queries, so it have all the sense in the world to reuse JSON for object representation. BSON is a more compact representation for that format.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I'm writing documentation for my AQA A-level Computing project. The project is a game which takes place in a Console application, which heavily depends on a series of classes and structures in a separate class library I have written. I don't know how to title the section in my documentation where I describe these classes and structures, and I'd like to know if there is a word that encompasses both concepts. Does the word "record" include both classes and structures, or is it tied to a specific implementation?
I'm aware that this is more English Language & Usage, but I thought it was more likely to get a response here where there are more programmers.
Yes, you could use the term record as objects/classes/structures are just differing types of records, or records with functions to handle the data in the record.
However, just to encapsulate all your possibilities, you should probably utilize the term Data Structure. I find that data structure is more common parlance than record.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a project which is using NodeJS and I have different entities for example, people and places.
I need the ability to find both types of entities by location together so what I was thinking of doing is having an index on a field called, type, for example, which would be either person or place and make use geospatial indexes, does this sound a good way to do this or is there a better way?
I will probably need a lot of joins too, so should I use MySQL alongside MongoDB and use MongoDB just for delivering the location based queries?
Thanks
This question is a poor fit for stackoverflow, but here's some radom bullet points:
PostgreSQL supports both joins and geospatial. I'd pick that first personally lacking other details warranting a different data store.
A totally valid option would be to keep people and places separate and query multiple collections as necessary. However, if you need to sort the results, then yes best to throw them in the same collection.
You could also keep people and places in separate mongodb collections but have a mapreduce job translate them into a locations collection for search purposes.
Generally, there are lots of ways to do this and the best one depends very much on the specific aspects of you application. Reads vs writes, data stability, data size, query load, etc, etc.
My broad word of advice is start with the most logical, easiest-to-follow, straightforward data organization (separate collections), and deviate from that when you understand the specific pain you have and how doing something more complicated or unusual will be an overall win.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I wonder what the best practice is to deal with a data model like this:
We have 3 entities:
Role
User
Permission
Note that the entities are represented as java classes and will be mapped to a database via hibernate, anyway I think the question could be answered without having knowledge of these technologies.
There is a many-to-many relationship between Role & User and between Role & Permission.
Is it ok to have a bi-directional relationship here? So, that you can ask Role to give you all his members and to ask User to give you all his roles.
It's very comfortable that you can ask both entities, however one drawback is that whenever you remove a relationship you have to manage both entities.
E.g. if you remove Role from a User you have also to remove the User from the Role. This can be quite annoying if there are many of these relationships. Therefore I would like what the best practice is.
I try to avoid bidirectional relationships. Instead replace one direction with an explicit query in you DAO/Repository. Keeps the model simpler and if done correctly via interfaces the application clean of circular dependencies
Is it ok to have a bi-directional relationship here? So, that you can ask Role to give you all his members and to ask User to give you all his roles.
Yes. If you actually need the navigability in both ways, then there's no reason to prevent yourself from obtaining it in the simplest way possible.
one drawback is that whenever you remove a relationship you have to manage both entities.
This depends on the implementation, one could implement the data model in a way that would synchronise both "ends".