I'm using ASP.NET MVC4 (EF Code-first) with WCF ADO.NET Data Service October 2011 CTP. I have an issue - I don't know how to ignore sensitive properties (like email).
I tried using an ADO.NET Entity Data Model (.edmx) and find the declaration of the sensitive property:
[EdmScalarPropertyAttribute(EntityKeyProperty=false, IsNullable=true)]
[DataMemberAttribute()]
public global::System.String MySensitiveProperty
{
get
{
return _MySensitiveProperty;
}
and changing the getter:
[EdmScalarPropertyAttribute(EntityKeyProperty=false, IsNullable=true)]
[DataMemberAttribute()]
public global::System.String MySensitiveProperty
{
get
{
return "No data here!";
}
Is there any better and simpler solution for my issue?
You can use the IgnoreProperties attribute. Simply decorate your class with this attribute and pass a list of property names to it. These properties will not be exposed to the data service. See here
In such case why do you expose that property? Once you do it this way you say that your application (no part of your application) never needs email property. In such case delete the property from entity mapped in EDMX and it will be never accessible.
Related
I have created a Model and i want to access model data annotation like DisplayName.
I have access model through WCF service layer. But WCF service remove all the Data annotation of the model.
[DisplayName("Student Name")]
public virtual string StudentName
{
get
{
return this.m_StudentName;
}
set
{
this.m_StudentName= value;
}
}
I want to access Display Name in the View but always I get null value in the DisplayName method in through the Property
A WCF service does not remove anything. However, building a service reference is making a copy of all the classes you have. And that copy is the smallest set neccessary to run the service.
If you need your full classes, put all those classes and interfaces you want shared into a common library that both your service and your client reference. This is commonly called a contract assembly. You can then either call the service directly through code or if you want to keep the wizard, you can use the checkbox that says "use classes in this project" when generating new types.
My project specifications are ASP.net MVC3 Application with Entity Framework.
The problem is that Customer wise the database will be created. Individual application individual database is working fine for me.
But i want a single application and multiple databases should be used with that.
How to achieve the same?
Instead of creating your entity connections using the default constructor and web.config-driven connection string, you need to manually build the entity connection string and feed it into it on construction using one of the other constructors. There's usually one that takes a string, and another that takes an EntityConnection instance as well.
If the only thing that changes is the name of the database, then you can probably get away with a format string - where you perhaps take the one that's currently in your web.config - which will look something like this:
metadata=res://*;provider=System.Data.SqlClient;provider connection string="Data Source=[server];Initial Catalog=[db];User ID=[user];Password=[password]"
Note - [server], [db], [user] and [password] here are placeholders.
And simply replace the [db] with {0}.
Then - assuming you can derive a database name from a user you might do something like this following:
public string BaseConnectionString {
get{
//TODO: Get base connection string - can just bake in the constant string with
//with the format placeholder. A better thing would be to add it as an
//AppSetting in web.config
}
}
//this now becomes you're primary way of getting a database connection for a user.
public MyEntities GetEntities(User user)
{
var eConnectionString = GetConnectionString(user);
return new MyEntities(eConnectionString);
}
public string GetConnectionString(User user)
{
var dbName = get_db_name_for_user(user);
return string.Format(BaseConnectionString, dbName);
}
This is but one way to achieve this. In an IOC environment it would be possible to hide all of this behind a simple Resolve<> call.
I use WCF with my ASP.NET MVC app, my data service get data from my (EF 4.1) .mdf file. But there is some feild that I want to show with authentication, for example:
public static void InitializeService(DataServiceConfiguration config)
{
config.SetEntitySetAccessRule("Exercies", EntitySetRights.All);
config.SetServiceOperationAccessRule("GetAllExercies", ServiceOperationRights.All);
config.DataServiceBehavior.MaxProtocolVersion = DataServiceProtocolVersion.V3;
}
[WebGet]
public IQueryable<Exercise> GetAllExercies(string name, string pass)
{
if (Membership.ValidateUser(name, pass))
return CurrentDataSource.Exercies;
else
return CurrentDataSource.Exercies.Where(e => e.Public == true);
}
Now when user access httx://localhost/MyService.svc/Exercies, they can get everything although they are not given the username and pass.
My temporary solution is re name GetAllExercies to just Exercies but I not sure is there any better way...
Yes, there is a better solution: query interceptors. In fact using the same name for entity set and service operation tends to lead to problems in certain scenarios (the $metadata is "confusing" for the clients). It's also not 100% secure (doesn't prevent accessing the entity through some navigation property if you have that).
See this http://msdn.microsoft.com/en-us/library/dd744842.aspx. The idea is that you make the auth filter part of the entity set query, and WCF DS Service makes sure that it will be used everywhere that entity set is accessed.
I develop a simple MVC3 CRUD application - simple controllers / views, which uses WCF service for CRUD data access.
The WCF uses EF4.1 with DbContext, and simple CRUD-style methods: ListEntities, GetEntity(ID), AddEntity (entity), DeleteEntity(ID)
If I develop the MVC application directly with EF, code first, I can annotate properties in the entity classes with validation attributes, and the MVC application will automatically recognize validation errors and report them in the UI when I try to save and a validation error occurs (e.g. a required field is not set).
But in my application I don't use this approach and I face two problems:
My entities in the WCF are generated from the EDMX, which in turn was also generated from the database. So I cannot actually add to them any data validation annotation attributes, because they'll vanish as soon as the entities will be regenerated from the EDMX. Is there any solution to this?
Since my client (MVC app) does not share the data contract classes with WCF (for clear separation), but instead it is generated form service reference, even if I find a way to add data annotation attributes to server-side data contract classes, will they be recognized and recreated when the data contract proxy class is created on client side?
So how could I made the MVC application to use client side validation and error message reporting for validation failures when binding to entities exposed by WCF service as data contracts?
One idea I have is, on client side, to create derived classes for all entities exposed as data contracts, and apply annotation attributes to them to desired properties. But this doesn't looks like a good solution to me, because with this I create a logic "coupling" between UI client and the WCF service / data layer (forcing UI to know about data more than it should do - by putting BL logic in client).
Can anyone give me some suggestions on how to handle those this situation?
Thanks
1: Yes you can add validation using the System.ComponentModel.DataAnnotations.MetaDataType.
I answered this question at MVC Partial Model Updates
2a: What you can do is create a seperate Class Library Assembly that contains all the interfaces (with or without additional MetaDataTypes) and use that on both the WCF service and the MVC application. After you add the reference to your MVC application, when adding the WCF Service reference, you can match the WCF Service DataContacts directly to the interfaces in the Assembly. One Caveat is that both the WCF service and MVC application are dependant on the Assembly (some might consider this tightly coupled) but this should be ok because you are only tightly coupling at the interface level, and whether or not you choose to allow VS to recreate it's own interfaces/classes or reuse what you already created in the Assembly it boils down to the same thing in my opinion.
2b: If you decide not to use a Class Library, I'm pretty sure that the service reference classes are partial, and you can simply create another .cs file with partial classes and add the interfaces as I described in part 1 to the partial classes.
Update
I am currently using Entity Framework to access my database. Entity Framework, like WCF References, classes are Auto-Generated classes will look something similar to:
[EdmEntityTypeAttribute(NamespaceName="MyNameSpace", Name="Info ")]
[Serializable()]
[DataContractAttribute(IsReference=true)]
public partial class Info : EntityObject
{
public static Info CreateInfo (global::System.Int32 id)
{
Info info= new Info ();
info.Id = id;
return info;
}
public string Name { get; set; }
public string FavoriteColor { get; set; }
// etc etc
}
In a separate file with the same namespace as the previous partial class, I have created:
[SomeAttribute1]
[AnotherAttribute2]
public partial class Info: IInfo
{
}
So now my auto-generated class is not only based on an Interface I created IInfo so the actual methods are not exposed (because my datatier in MVC returns interfaces), but it also has Attributes (for Data Annotations or whatever).
What I would suggest is instead of putting your data annotations directly on your WCF Service reference class is to use the MetedataType DataAnnotations. This allows you to separate the actual data object with the data annotations validations. Especially helpful if you want to use the same data class with different validations based on whatever (maybe administrators don't have to have a valid favorite color).
For example:
public interface NormalUser
{
[Required]
string Name { get; set; }
[Required]
string FavoriteColor { get; set; }
}
public interface AdminUser
{
[Required]
string Name { get; set; }
string FavoriteColor { get; set; }
}
[MetadataType(typeof(INormalUser))
public class NormalUserInfo : Info { }
[MetadataType(typeof(IAdminUser))
public class AdminUserInfo : Info { }
In this example we have two different classes NormaUserInfo and AdminUserInfo which both have different validations. Each of them have inherited from Info so they are valid models that can be passed into the WCF Service.
Out of my mind, as I can't test it right now...
Let's say your autogenerated code is like this:
public partial class Employee
{
//some code here
}
You can add a new Employee class, also partial, and this one won't be autogenerated
[you can annotate here]
public partial class Employee
{
//somecode here
}
try it
As for the validation, you could use: http://fluentvalidation.codeplex.com/
I need to make a web application and I want to use MVC. However, my Model can't be one of the standard Models -- the data is not stored in a database but instead in an external application accessible only via a API. Since this is the first MVC application I've implemented I'm relying on examples to understand how to go about it. I can't find any examples of a non-DB based Model. An example of a custom Model would be fine too. Can anyone point me to such a beast? Maybe MVC is just to new and none exist.
It seems like I might be able to get away with the DataSet Model, however I've not seen any examples of how to use this object. I expect an example of DataSet could help me also. (Maybe it is the same thing?)
Please note: I've seen countless examples of custom bindings. This is NOT what I want. I need an example of a custom Model which is not tied to a specific database/table.
UPDATE
I found a good example from MS located here:
http://msdn.microsoft.com/en-us/library/dd405231.aspx
While this is the "answer" to my question, I don't really like it because it ties me to MS's view of the world. #Aaronaught, #jeroenh, and #tvanfosson give much better answers from a meta perspective of moving my understanding (and yours?) forward with respect to using MVC.
I'm giving the check to #Aaronaught because he actually has example code (which I asked for.) Thanks all and feel free to add even better answers if you have one.
In most cases it shouldn't matter what the backing source is for the actual application data; the model should be exactly the same. In fact, one of the main reasons for using something like a repository is so that you can easily change the underlying storage.
For example, I have an MVC app that uses a lot of web services - rarely does it have access to a local database, except for simple things like authentication and user profiles. A typical model class might look like this:
[DataContract(Namespace = "http://services.acme.com")]
public class Customer
{
[DataMember(Name = "CustomerID")]
public Guid ID { get; set; }
[DataMember(Name = "CustomerName")]
public string Name { get; set; }
}
Then I will have a repository interface that looks like this:
public interface ICustomerRepository
{
Customer GetCustomerByID(Guid id);
IList<Customer> List();
}
The "API" is all encapsulated within the concrete repository:
public class AcmeWSCustomerRepository : ICustomerRepository, IDisposable
{
private Acme.Services.CrmServiceSoapClient client;
public AcmeWSCustomerRepository()
: this(new Acme.Services.CrmServiceSoapClient())
public AcmeWSCustomerRepository(Acme.Services.CrmServiceSoapClient client)
{
if (client == null)
throw new ArgumentNullException("client");
this.client = client;
}
public void Dispose()
{
client.SafeClose(); // Extension method to close WCF proxies
}
public Customer GetCustomerByID(Guid id)
{
return client.GetCustomerByID(id);
}
public IList<Customer> List()
{
return client.GetAllCustomers();
}
}
Then I'll also probably have a local testing repository with just a few customers that reads from something like an XML file:
public class LocalCustomerRepository : ICustomerRepository, IDisposable
{
private XDocument doc;
public LocalCustomerRepository(string fileName)
{
doc = XDocument.Load(fileName);
}
public void Dispose()
{
}
public Customer GetCustomerByID(Guid id)
{
return
(from c in doc.Descendants("Customer")
select new Customer(c.Element("ID").Value, c.Element("Name").Value))
.FirstOrDefault();
}
// etc.
}
The point I'm trying to make here is, well, this isn't tied to any particular database. One possible source in this case is a WCF service; another is a file on disk. Neither one necessarily has a compatible "model". In this case I've assumed that the WCF service exposes a model that I can map to directly with DataContract attributes, but the Linq-to-XML version is pure API; there is no model, it's all custom mapping.
A really good domain model should actually be completely independent of the true data source. I'm always a bit skeptical when people tell me that a Linq to SQL or Entity Framework model is good enough to use throughout the entire application/site. Very often these simply don't match the "human" model and simply creating a bunch of ViewModel classes isn't necessarily the answer.
In a sense, it's actually better if you're not handed an existing relational model. It forces you to really think about the best domain model for your application, and not necessarily the easiest one to map to some database. So if you don't already have a model from a database - build one! Just use POCO classes and decorate with attributes if necessary, then create repositories or services that map this domain model to/from the API.
I think what you are looking for is really a non-DB service layer. Models, typically, are relatively simple containers for data, though they may also contain business logic. It really sounds like what you have is a service to communicate with and need a layer to mediate between the service and your application, producing the appropriate model classes from the data returned by the service.
This tutorial may be helpful, but you'd need to replace the repository with your class that interacts with the service (instead of the DB).
There is no fixed prescription of what a "Model" in MVC should be, just that it should contain the data that needs to be shown on screen, and probably also manipulated.
In a well-designed MVC application, data access is abstracted away somehow anyway, typically using some form of the Repository pattern: you define an abstraction layer (say, an IRepository interface) that defines the contract needed to get and persist data. The actual implementation will usually call a database, but in your case should call your 'service API'.
Here is an example of an MVC application that calls out to a WCF service.