Pass objects or values to functions [closed] - c#

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
This question has been edited to ask about a specific example as the original question was deemed unanswerable.
Given an application that needs to display information about various objects (including similar and inherited objects) would it be better to pass in base class objects to the display function and allow it to query the object to determine what data to display; or should you just pass in each of the fields by value. The advantage of passing by value being do not need a direct dependency on the objects they representing, thus keeping the display (UI) isolated from the business rule objects.

In general, you should pass the minimum amount of information that a method needs to do its job. For example, if a method is computing a person's age given their birth date, you don't need to pass in the entire Person object, you just need the person's birth date and the current date.
By following the above approach, you keep your methods loosely coupled, which makes them much more maintainable.
In your case, you have to balance whether you need to access a lot of fields of the base classes in these methods, or if you are just need to access a few. If it's a lot of fields, then it may make more sense to just pass the entire object. It's sort of a balancing act between having good coupling (see first part of this answer), but at the same time, avoiding passing tons of parameters to a method.

Related

pass objects in WPF XAML [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 9 years ago.
I am new to coding GUI stuff, and I was wondering if anyone could tell me whether there is a way to pass objects in xaml to the constructor of another FrameworkElement.
Right now, I am using the code-behind to send an object that does not derive from any of the allowed types in XAML. However, If I were to make the class being passed derive from frameworkElement as well, would it be possible to pass it as an object to a constructor or perhaps set a field to it?
for example
or can properties only be normal value types and is there no way to use constructors beside the default one?
As I said I am currently just passing stuff to the constructor in the C# file that goes with the xaml, but I feel like it would be convenient if it were possible to pass with xaml.
Your doing it wrong.
Unless you are writing a real "user control" There should be very little logic in your view code behind or view constructor. Instead almost all of the logic should be in either View Model or Model types that get into your view through data binding.
This of course isn't always 100% possible, in which case the 'Field' you are looking for is called DataContext. You can set this to an object and then subscribe to the DataContextChanged event and do whatever view specific logic you need there.
see http://msdn.microsoft.com/en-us/magazine/dd419663.aspx among others for more.

Why can you make Primitive Datatypes in C#? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
How come that in C# you can make Primitive Datatypes?
What kind of practical uses does this functionality have?
I assume you mean struct. There are various uses:
representing simple data such as a Point or ComplexValue that doesn't warrant the overhead of an object per instance : it is just a (preferably-immutable) set of values that are a composite
mapping fields to memory with explicit layout for interop purposes
avoiding GC issues for massive datasets
It is, however, very rare to declare a struct in C#; i.e. vanishingly rare. Nobody is making you do it, and if you don't like them : don't create any.
There is no such thing as 'primitive' datatypes if you're coming from Java world. All of those so called primitive data types are objects in System namespace (from MSDN).
You can, however, create user defined types.. and that is the whole concept of "class" and "enums" and "structs".
See here for understanding what "primitive" data types in C# actually mean:
primitive datatypes in C#

Why should a data access layer be abstracted? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
Interface should be used when none of the implementation details are available to the current scope of the code.
Abstracts should be used when some of the implementation details are available to you.
Query - Why still these terms are required? Why can't Business objects directly communicate with DataAccess.SqlServer Layer?
Interface should be used when none of the implementation details are
available to the current scope of the code.
Not really. What you're referring to is encapsulation. There is the concept of "information expert." Only the class that knows how to do something should be the one doing it. Interfaces are used for polymorphism and decoupling. When consuming code wants to treat certain types of objects the same way, that code can use all of those objects the same way by treating them as the interface type.
Abstracts should be used when some of the implementation details are
available to you
I'm not sure what you mean here. I think you're confused because this doesn't sound right. Abstract classes are used the same way interfaces are, except that they're allowed to have implementation in them.
Query - Why still these terms are required? Why can't Business objects
directly communicate with DataAccess.SqlServer Layer?
They can, but at the cost of maintainability, flexibility, and testability. If you want to replace your data layer with another, you can't because the consuming code has a direct dependency on the current data layer. If you want to unit test your logic, you can't without hitting the DB. If you put your database classes behind an interface, you could mock the data layer in unit testing and test your logic classes without hitting the database.
Very Short Example
public Foo FooLogic
{
IFooData fooData = DataAccessFactory.GetDataClass<IFooData>();
return fooData.GetFoo();
}
Now your logic class isn't tied to a particular data class. The factory can return a real FooData implementation, or it can return a mock data object, or a new data access layer can be put in place without affecting the code in the logic class.

How to deal with multiple xml standards? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 10 years ago.
I am attempting to write a local set of wrapper classes into our institution API (I work at a post secondary institution). The purpose of these classes are to securely pull transcripts from a remote service, and to allow the abstraction away from how that service works to our programmers. How the service works is confidential however the question I need an answer too is this:
How to deal with this when each transcript response comes in a different xml format depending on which of the schools it comes from. There are over 30.
As an example: Institution A has the tag, at the top of the document near the root, for GPA of a student to be |GPA|4.0|/GPA| whereas another institution might have it in a completely different part of the XML, near the bottom and perhaps 3 children deep, and name the tag |GradePointAverage|4.0|/GradePointAverage| (Pretend | is xml angle brackets)
Any suggestions how to deal with this lack of standardization?
It sounds like you should aim for one common data model, and then 30 different classes which are able to deserialize from XML to that data model. Depending on exactly how different they are, there may be significant aspects of reuse, and you may even be able to parameterize some differences. Using LINQ to XML makes it reasonably easy to parse any one format.
I would aim for lots of simple code rather than a small amount of "clever" code: parsing each individual format should be reasonably straightforward, and hopefully easy to test. Yes, it'll be tedious to write this code, but it should end up being easy to follow, and easy to add more formats if you need to.
You could use XSLT to perform a transformation into a single format of course, but personally I'd rather write C# :)
This assumes you can create a common data model - if the formats are very different, you may find that you can't accurately represent the data in each file without having a horrible lowest-common-denominator. Coming up with a good data model is likely to be as hard as writing each individual parser.

Design-time alternatives to a GUID? [closed]

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.
Closed 11 years ago.
This isn't a complicated question. I was just thinking through best practice and thought the community might be able to help.
SOLUTION
Have one file that contains an enumeration. Source control can take care of collisions between multiple projects / developers. If all assemblies are compiled and deployed at the same time, the ID will be unique (if cast to int). Alternatively, we could assign a number to each enum. The enum file will be added to each project via "Add As Link".
Original question
I'd like a unique id that begins at one, is set at design time, and is easy to implement in code to identify different classes. In Visual Studio, we have a Tools / Create GUID. That's convenient, but at 16 bytes it's a little larger than I'd like.
It'd be nice to able to retrieve unique sequential integers from a web service.
Has someone already done this? Does such a service already exist?
One alternative is to have a file that acts as a central register for developers... but I'd rather not if possible. It would be nice to have two steps: 1. create class, 2. assign id. Done.
You can create this yourself if you want, make a web service and generate numbers. If you generate the number at design time, alter your code at design time so that no other program cares what your magic number is.
GUIDs can be created relatively quickly on anyone's computer. This means that you don't have to have some "central" database for numbers, which assists performance of certain applications. Otherwise, use the GUID, which is a globally unique identifier that you can generate at run time and design time.

Categories