I am having two namespaces with two classes with same Name something like this "public partial class CustomerDetail" one from "namespace MS.Client" which implements "IClient" Interface and another one from "namespace MS.Customer" which implements "ICustomerInfo" Interface both in different assembly as well. am trying to access "CustomerDetail" from some other "namespace MS.Applications.View" which has a reference for "namespace MS.Client" but when I suppose to instantiate the "CustomerDetail" class in "namespace MS.Applications.View" I would except all the properties that belongs to "CustomerDetail" in all the namespaces correct? but it was not actually working. can any one help me out from this?
namespace MS.Client
{
public partial class CustomerDetail : IClient
{
private string name;
public string CustName
{
get { return name; }
set { name = value; }
}
private string address;
public string CustAddress
{
get { return address; }
set { address = value; }
}
}
}
namespace MS.Customer
{
public partial class CustomerDetail : ICustomerInfo
{
private string name;
public string Name
{
get { return name; }
set { name = value; }
}
private string address;
public string Address
{
get { return address; }
set { address = value; }
}
}
}
please let me know if any one cant understand my summary.
No, classes are local to their namespaces and thus, you can not modify a class from a different namespace. All classes have a fully qualified name, which is their real name, and the namespace is part of it.
What you are actually doing in your code is defining two different CustomerDetail classes, each in a different namespace, effectively being: MS.Customer.CustomerDetail and MS.Client.CustomerDetail.
In order to achieve what you are trying, you need to change to change one of the namespaces so they actually match and the CustomerDetail are actually the same (i.e. they have the same fully qualified name since they are prefixed by the same namespace and have the same name).
Related
New to Jersey(REST Framework for Java) and I'm trying to setup two resources, in two separate classes that share a root path, and I'm having a problem.
So, I have something like:
#Path("/users")
public class User extends RestSupport {
#GET
#Path("/{user_uuid}")
public String get(#PathParam("user_uuid") String uuid) {
return "Hello User " + uuid;
}
}
The above class works. However, I want to create a child resource in a separate class. But when I do this, it seems to create a URI naming conflict. So, here, I want to get all the pets for a particular users
#Path("/users")
public class Pets extends RestSupport {
#GET
#Path("/{user_uuid}/pets")
public String get(#PathParam("user_uuid") String uuid) {
return "Hello Pets " + uuid;
}
}
These top-level resources have lots of child resources, so I'm looking for the best way to organize them. Any help would be appreciated.
Change the path of Pets class from #Path("/users")to#Path("/users/{user_uuid}/pets")
Don't add the HTTP annotation #GET on your Users root resource method if you want Jersey to delegate calls to a child resource. Consider a User class:
public class User {
String uuid;
User(String id) { this.uuid = id; }
#GET
public String get() { return "Hello user " + uuid; }
#GET
#Path("/pets")
public String getPets() { return "Hello pets " + uuid; }
}
and then adjust your Users resource:
#Path("/users")
public class Users {
#Path("/{user_uuid}")
public User get(#PathParam("user_uuid") String uuid) {
// Get the user from the DAO here...
return new User(uuid);
}
}
First of all, I have read this post and did not find the answer for my problem.
I am not sure if this is an aggregated Model class or an aggregated ViewModel class, but this is what I have:
In my WPF (with Prism) application, I have a view 'Filter Customers View' that connects to a service and requests a list of 'Customer' objects, based on a filter.
The list that is returned from the service is this :
List<CustomerDTO> FilteredCustomers;
And the CustomerDTO looks like this:
public class CustomerDTO
{
public Guid CustomerId;
public String Name;
public String Address;
public String PhoneNumber;
public OrderInfoDTO LastOrderInformation;
public List<OtherClass> ListOfSomething;
}
And the OrderInfoDTO looks like this:
public class OrderInfoDTO
{
public Guid OrderId;
public DateTime OrderDate;
public int NumberOfProducts;
public double TotalAmountSpent;
}
And the OtherClass looks like this:
public class OtherClass
{
public Guid Id;
public String SomeText;
}
As you can see - the customer might or might not have a 'Last Order',
I would like to wrap the 'CustomerDTO' object in a ViewModel,
so that I can bind it to the view.
This is what I thought of doing :
public class CustomerViewModel : NotificationObject
{
private CustomerDTO _customerDTO;
public CustomerViewModel(CustomerDTO customerDTO)
{
_customerDTO = customerDTO;
}
public Guid CustomerId
{
get { return _customerDTO.CustomerId; }
set { _customerDTO.CustomerId = value; RaisePropertyChanged("CustomerId "); }
}
public String Name
{
get { return _customerDTO.Name; }
set { _customerDTO.Name = value; RaisePropertyChanged("Name"); }
}
public String Address
{
get { return _customerDTO.Address; }
set { _customerDTO.Address = value; RaisePropertyChanged("Address"); }
}
public String PhoneNumber
{
get { return _customerDTO.PhoneNumber; }
set { _customerDTO.PhoneNumber= value; RaisePropertyChanged("PhoneNumber"); }
}
}
.
Questions:
First of all - is 'CustomerDTO' what is known as a Model ? And is 'OrderInfoDTO' also a Model ? and what about 'OtherClass' ?
How do I treat the 'OrderInfoDTO' in my CustomerViewModel class ? Do I create a 'ViewModel' for it also ? where do I create the 'OrderInfoDTO' view-model ??? What happens if now someone updates the customer and sets the 'OrderInfoDTO' value ?
How do I treat the list of 'OtherClass' in my CustomerViewModel class ? Do I create an ObservableCollection for it ? What happens if someone will want to delete an item in it or update an item in it or add an item to it ?
Think about it this way:
The View is your UI that you would bind elements from the View Model to using the {Binding Path=, Mode=TwoWay -- If you want to update based upon the user input
The Model is only the data, this could a record set, file, database records etc. So CustomerDTO and OrderInfoDTO are models.
The View Model is your link between the data (Model) and the UI (View). It will allow to you change the data so it's easier to present on the UI
You would need to use ObservableCollection in all instances where there's a list that could change in the background.
You don't need a view model for OrderInfoDTO unless you need a view to update that data. If you are presenting a CustomerDTO info with OrderInfoDTO in it, then making it a property of the CustomerDTO view model would be fine.
I am learning some good code practice that's why i was going through some code, some thing i could not understand in it. It has made property in a separate class for each entity like in userClass it has property
#region public properties
private int uid;
public int userId
{
get { return uid; }
set { uid = value; }
}
private string uName;
public string userName
{
get { return uName; }
set { uName = value; }
}
private string pwd;
public string password
{
get { return pwd; }
// set { pwd = value; }
}
private string uAddress;
public string userAddress
{
get { return uAddress; }
set { uAddress = value; }
}
private string fName;
public string firstName
{
get { return fName; }
set { fName = value; }
}
private string lName;
public string lastName
{
get { return lName; }
set { lName = value; }
}
private string uPhone;
public string userPhone
{
get { return uPhone; }
set { uPhone = value; }
}
private string uMobile;
public string userMobile
{
get { return uMobile; }
set { uMobile = value; }
}
private int secretQuestion;
public int securityQuestion
{
get { return secretQuestion; }
set { secretQuestion = value; }
}
private string userAnswer;
public string answer
{
get { return userAnswer; }
set { userAnswer = value; }
}
#endregion
and from the business logic class it uses the property instead of using directly any entity's attribute name, but i am confuse whats there need to make a property like this?
other then this it has got enums for database column name which has a clear reason behind this that if in near future we have to change the database table's fields name then we don't have to change through out the whole business logic class and we can make changes to enum directly, But what is there use of creating property like this please elaborate me on this
Are you really asking why it uses properties instead of having public fields?
Fields are an implementation detail - they're how data is stored, which shouldn't be something the outside world cares about, at least for 99% of types. Properties are part of the contract that a type has in terms of its API - the implementation is up to the type. In other words, it's a matter of encapsulation. Properties can be expressed in interfaces, as abstract methods etc, precisely because they keep the contract and the implementation separate.
Additionally, properties make databinding, debugging and various other things simpler. I have an article about why properties matter, which you may find useful.
Having said all of this, those properties are implemented in a tedious way - and they don't obey .NET naming conventions. I would have written them as:
public int UserId { get; set; }
public string UserName { get; set; }
public string Password { get; set; }
// etc
Properties can be defined on Interfaces, but member fields cannot. So if you needed to refactor this class to a class that implements an interface, you can put the properties on the interface (and then have other classes that implement them as well.)
Some similar questions:
Public Fields versus Automatic Properties
Property vs public field.
In additional to above: Actually you can easily decide public field or property by yourself. It is quite easier to understand that:
(1) Name is a property of class Person
(2) Speed is a property of class Plane
(3) Empty is a public field of class String. If you say String has a property named Empty, it's really weird. And String has a property Length is easy to understand.
I think we can all agree that Automatic Properties in C# 3.0 are great. Something like this:
private string name;
public string Name
{
get { return name; }
set { name = value; }
}
Gets reduced to this:
public string Name { get; set; }
Lovely!
But what am I supposed to do if I want to, say, convert the Name string using the ToUpperInvariant() method while "setting". Do I need to revert back to the old C# 2.0 style of creating properties?
private string name;
public string Name
{
get { return name; }
set { name = value.ToUpperInvariant(); }
}
Or is there a more elegant way of accomplishing this?
Yes, you have to convert it back. An autoproperty can't do this kind of checks.
I'm familiar with this new syntax sugar:
public string Name { get; set; }
But what if I was the setter of that variable to have some sort of checking. For example, I want to convert the entire string that is supposed to be Set to all lowercases.
public string Name
{
get;
set
{
????
}
}
You will need a backing field for both the getter and setter (you can't have a partially automatic property):
private string name;
public string Name
{
get
{
return name;
}
set
{
// do validation or other stuff
name = value.ToLower();
}
}
You can't define a partially-automatic property. You would have to do things the old fashioned way: define backing field and implement the getter and setter logic yourself.
private string _name;
public string Name
{
get {return _name;}
set
{
_name = value.ToLower();
}
}
Then you cannot use the auto generated get/set feature:
string _name;
public string Name {
set { _name = value.ToLower(); }
set { return _name; }
}
public string Name { get; set; } These are called Auto Implemented Properties. In C# 3 and later you can use this syntax for property. But if you want to do any operation on the value before setting, then this is not helpful . One more disadvantage is ,you have to use both set and get,you can't declare only getter. Alternate is to make the setter private. In your case, you have to use the older version of properties.
private string _name;
public string Name
{
get {return _name;}
set
{
//do any operation
_name = value.ToLower();
}
}