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 4 years ago.
Improve this question
I would like to build some sort of survey/ auditing software.
I am brainstorming how to build my classes and if there is a design pattern that could support me. Because ther must be something that makes life eaysier...
My application should have questions which contains a title and a description.
And then I have multiple types of answers.
So... one type could be a yes/no answer
Another type could be a value between 1 and 10.
Another type could free text answer
Another type could be a three given text choices where you can select one (The dinner was excellent, good, nod bad)
So on the survey planning site I would write down my questions and assign answer types.
And on executing the survey I want to tread it like a collection of questions with an answer...
Basically the question is how to unify all the different answer types and how to store them in the database?
I looked at composite and strategy pattern but I am not sure...
and I know there is not perfect solution and it always depends...
But it would be great if someone can share best practice on how they dealed with similar topics...
Thanks in advance...
What you seem to be asking here is what are the different entity mapping strategies that are available to you in the database? In short you can have:
a table per entity
a single table for all entities with a discriminator value to identify each one (values could be just a tokenized string for example) - essentially a big Map
a table per entity with 1:1 join for optional properties
Your ORM solution then reads the data back from the database and turns it into the appropriate type of object (the entity) populating the fields as it goes.
In terms of the middle tier, you will need the following classes:
AbstractQuestion
An abstract base class for questions. Containing title, description and abstract ask() and answer() methods. There will be a variety of subclasses for AbstractQuestion that provide different display messages depending on the type of question. For example, MultiChoiceQuestion will implement the ask() method in such a way that the title and description get displayed (you could pull this up into the AbstractQuestion ask() method) along with all the choices available (which is specific to each subclass). This could be generalised so that ask() takes a Map as a parameter which can be populated with anything you like. Or you could use varargs - whatever.
Answer
Just a simple class containing a Map with known keys representing the different aspects of the answer with a reference to the owning AbstractQuestion.
Questionaire
A collection of AbstractQuestions arranged in a list. For each AbstractQuestion call the ask() method, wait for user input, then call the answer() method with the provided data.
No need for complex design patterns, unless you count abstract base classes as a pattern. The above is not complete, but it should be enough to get you started.
Related
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 3 years ago.
Improve this question
I have different product types that have different attributes. They cannot be stored in a single table as the attributes are too distinct. There's a couple of options I'm currently looking at: EAV and a table for each type.
My situation is, at the moment, there are only a number of types (lets say 8) but in the near future with almost 100% certainty, this can grow. But the growth is controlled by me, its not defined by users. It will be up to me to grow the product type.
I'm currently inclined to use EAV (for the reason that I can cover the growth easily - I think) but I am not sure as I'm concerned with the performance as well as modeling them in my language of choice (C#). My question is, given the scenario above, is it better for me to create a single table for each product type and add as necessary, or would this be a good case (or not even good, lets say acceptable) to use EAV?
There's no short good or bad answer to this concern, because it depends of many things.
Do you have a lot of product types ?
How do you think each of them will evolve (think to what will happen when you will add new fields to products) ?
Do you need to handle "variants" of the products ?
Do you intend to add entirely new types of products ?
Etc.
EAV is probably a good way to go if you answer if you answer "yes" to some or all these questions.
Regarding C#, I have implemented in the past an EAV data catalog with it, and using Entity Framework over SQL Server (so a RDBMS).
It worked nice to me.
But if you need to handle a lot of products, performance can quickly become an issue. You could also look for a "NoSQL" solution, did you think about it ?
Just keep in mind that your model object does not have to match your data model.
For example you could perfectly have a stronly typed object for each type of product if you need so.
Much depends on the operations that will be performed on entities. If you will:
often add new attributes to products;
add a lot of products type;
implement full product type search (or other "full product type" feature);
I recommend you to use EAV.
I have implemented in the past EAV data structure with ADO.NET and MS SQL and don't have any problem with performance.
Also, Morten Bork above recommend use "sub types". But if you want implement some "full product type" features, I think it will be more difficult then use pure EAV model.
EAV doesn't really play well with a relational database. So if that is what you are doing. (IE connecting to SQL) Then I would say no. Take the hit in development time, and design a table pr type of product, or make a aggregate table that holds various properties for a product type, and then connect the properties to the relevant tables.
So if a product contains "Cogs" then you have a table with "teethcount", "radius" etc.
Another product type has "Scews" with properties "Length", "riling" etc.
And if a product type has both cogs and screws, it merely has relation to each of these subtypes.
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 6 years ago.
Improve this question
I have a class/object called "User" that has about a dozen properties (eg: UserGUID, UserName, etc.). It has a constructor, static methods, couple other helpers/support methods, etc.
The website has hundreds of functions/methods where 2+ parameters come from the User object. For example:
public string HelloWorld(Guid userGUID, Guid accountGUID, bool somethingElse)
{
//Do something
}
I really want to pass in the User object itself to make the call cleaner and not have to keep adding parameters everytime I need a new value from the User object. Like this:
public string HelloWorld(User user)
{
//Do something
Guid userGUID = user.UserGUID;
}
So my question is, at what point is passing in the object good/bad vs passing in several parameters? Does it depend on the size of the object? How would I determine what's "too big" vs "OK"? Is it the number of parameters? How many params is too many?
You should think about what the method is supposed to do . Why does the method exist?
The semantic of the method will determine its arguments. So, for example, if HelloWord is supposed to print some stuff out, like a userId, and something else, then the signature should contain userId and something else as arguments.
On the other hand, if HelloWord is supposed to print out some information about a User, then the method signature should have the object User as a parameter.
It all depends on the method semantic.
In Clean Code, Robert Martin says to prefer 0 arguments, 1 or 2 arguments are acceptable and 3 is too many.
In my opinion as long as you're in the same process I think passing the object is preferable to passing arguments. You wouldn't want to send (or receive) more than is needed to another process (say a web service).
I highly recommend Clean Code, it's a good read and has a lot to say about structure.
There is a very important difference here, and this is not an opinion.
I have a class/object called "User" that has about a dozen properties
Given the above situation, if you were then to allow (User user) as opposed to only allowing (Guid userGUID, Guid accountGUID, bool somethingElse) you have just introduced a security hole.
Clients would be able to send more data than they were supposed to have access to by posting the extra names of the User class. For example, it is possible for a client to alter foreign navigation property keys in this fashion if you make the entire class available (and it had foreign relations). It is also possible for clients to alter timestamps, and even logical separations depending on information stored in that class.
Preventing this type of breach is easy to do if you allow the entire class to be accepted, you just need to then manually inspect each property to make sure it wasn't erroneously sent, or screen it by only selecting the subset of information sent. Either way, this is a bad idea.
While there may be no difference in using a User class with the same properties as the 3 shown, allowing the model binding of a User class which has a larger set than the 3 can be problematic if left unchecked.
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 7 years ago.
Improve this question
Is there any preference on either appending DTO or Entity to a class name?
Is there any standard around this?
1 Class is used by ORM (EntityFramework) and the other class is used for serialization.
The reason for this is so that there is no duplication of all fields as the EntityFramework is a wrapper around the DTO class(most but not all properties).
The DTO class is in a shared library, and decoupled from EF.
E.g. Which of these is the most common/standard approach?
// 1.
MyNamespace.Entities.MyClass
MyNamespace.Models .MyClassDto
// 2.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClass
// 3.
MyNamespace.Entities.MyClassEntity
MyNamespace.Models .MyClassDto
In my personal experience your third example is the only implementation I have worked with and it is the one I would argue for because the intent of the object you are working with will always be clear whereas with the other two it only becomes clear when looking at both objects together.
That being said as long as your team comes to an agreement on which to use any would work.
In my opinion, you typically don't want to put implementation details into class names for similar reasons to why you don't want to use Hungarian Notation.
If there's a bit of code that needs to work with both types and differentiate between them, another option is including aliased using statements like this:
using entities = MyNamespace.Entities;
using dto = MyNamespace.Models;
//in code
var myClassEntity = new entities.MyClass();
var myClassDto = new dto.MyClass();
//work with both
My assumption is that the code that needs to work with both types is limited to an isolated library, and that client code typically works with one, not both types.
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
Original Questions: I know the question sounds pretty "thin", since generic classes (interfaces) and collections go hand in hand. Out of curiosity and a desire to 'cover all the bases' ... are there uses for these generics other than as collections?
The response is that there are too many possibilities to make for a good thread, so let me try to clarify the question because I ( and probably others) will definitely benefit.
My revised question is:
What are applications of instantiated generics (not methods!) in addition to collections? So, now I know there are many ... however, classified by use... what are they?
A concise format for answers is:
Use: Short description or example
(ie) Collections: The generic allows for collections of objects and with a where T: constraint gives access to methods on all members of the collection. (link or reference).
I'm really eager to hear responses.
You can create not only generic types but also generic methods. Though the most common use of generics is for creating collections they are also used for many other purposes such as containers or algorithms.
class Point<T>
{
T x;
T y;
};
class Math<T>
{
T Add(T a, T b);
};
You should also have a look at this discussion: What is cool about generics, why use them?.
I've used generics for a "EventHandler" (with a restriction on the generic that the parameter implemented my BaseEvent class) when sending events via WCF to another piece of the system.
As the comments note, the answer is unequivocally yes. You use generics whenever multiple types (and ideally all types) should have the same behavior (and occasionally state). Collections are an easy example of this, but there are many, many other situations where this holds true and generics are a good choice.
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 am designing a C# ASP.Net web application that uses a lot of common functionality and the right way to deal with that seems to be through inheritence. I plan to make a base class (Person) and the inherit it in other classes like Employee and Vendor, and then in turn inherit Employee with Manager, etc. That way I don't have to define common properties such as FirstName, LastName, PhoneNumber, etc. on each one of them.
The second part of the questions is this: If I use inheritence and use Entity Framework's CodeFirst entities, will they understand the inheritence? How will the data be stored in the tables? Will each table have a FirstName and LastName column, or is EF smart enough to make them a common table?
I am really hoping someone who is a REAL object oriented programmer out there can help me clear this up. I have gotten a lot of conficting information and I need someone with actual experience on EF projects to give me some guidance. Am I understanding inheritence right? If not, what am I getting wrong? Any help is appreciated.
Thanks,
Bert
This is not an easy question, but for most cases it's better to choose composition instead of inheritance. You should not derive cash dispenser from calculator just because calculator has display and keyboard properties. It's ridiculous.
But sometimes inheritance makes sense. Ask yourself, should those classes have 'is a' relationship? As I see your task, it's better to make Vendor and Employee to be independent classes, both have Person property. And derive Manager from Employee.
Nevertheless keep depth of inheritance as little as possible. Deep hierarchies are pain to debug and understand, especially if there are many method overrides.
For more inspiration about the topic have a look at Chad Myers blogpost.
From an object-oriented perspective, the problem with that approach is when a person becomes a manager, a employee, a vendor or all of them. In some latin languages we have to forms for the verb to be (ser/estar). The former refers to the nature of the being and later to the state. It is better to use isA for inheritances when refers to the nature of the being rather than its state. In your case, I would recommend using roles. A person has many roles. Manager is Role (Manager inherits from Role), Employee is Role, etc. This way, you can reuse your person attributes and you can add and remove roles of a person.
First 1: Sounds good. But make sure that an "is a"-relation is given. Do not derive Person from Address just to include the Address-specific properties - use EF complex types for this kind of reuse.
One issue that comes to my mind: Are you sure that Vendor is a sub type of Person?
More on that: make sure that you stay within "one domain" with your inheritance. As Vinny posted in another possible answer, if the same Person could be Manager AND CustomerContact and both inherit from Person you run into a problem. However, if managers and customer contacts are not within the same domain it is probably better to add the person data twice - maybe the same person wants to have you different contact data as manager than as customer contact.
Part 2: You can choose what EF generates:
http://www.entityframeworktutorial.net/code-first/inheritance-strategy-in-code-first.aspx