In my ASP MVC project, whenever I add a new table to my project two models are created. One under the Text Templating Transformation Toolkit (file w/.tt extension), and another outside this in the general Models folder (this one seems to want to default with a "1" at the end of the file).
Whenever a change is made to the database, it seems all the models under the .tt file are refreshed according to the fields currently existing in the database on that table. The files outside this is the general Models folder, however are left as they were. Because of this, we have put all of our model validation methods in these .cs files (with the "1" at the end of the file name).
However, in one instance I needed to remove a field from the model under the .tt file in order to perform a validation in the other .cs file. This is the validation I perform:
private string agentId;
//here, AgentId overrrides the field in the BankListAgentId.cs file,
//which MUST be commented out.
[DisplayName("Agent ID")]
public string AgentId
{
get { return agentId; }
set { agentId = this.scrubAgentId(value); }
}
Is there a way to specify in this .cs file that the AgentId field here (the file with the "1" at the end of the name) overrides the AgentId field in the.csfile found under the.tt` file?
As far as I know it can't be done. But there are few tricks that can you do.
Change name of your property to eg. InternalAgentId and also change in EDMX that field to be protected or even private. Then in your code reference to InternalAgentId:
public string AgentId
{
get { return this.InternalAgentId; }
set { this.InternalAgentId = this.ScrubAgentId(value); }
}
If you need that property in linq you can look at Microsoft Linq Translation
Another way is to change your T4 to generate partial methods and invoking it inside generated properties. I think that one of Entity Framework template already do that.
Related
I am starting an MVC project and designing my DB in EF, which means I design the tables, and VS creates the classes I need to access them.
The problem is, I want to make use of attributes like DisplayName, Required and generating validation error messages ( including specifying rules to validate ).
As far as I can see, the classes are recreated every time I change my DB, so I can't really add them to the classes. Is there another way to do this once and have it persist ?
So you would use the MetadataType attribute and link your entity to a type where you'll set the validation attributes.
Something like this for an Entity Person:
[MetadataType(typeof(Person_Validation))]//<<link to metadata class
public partial class Person//<<<Your real entity class
{//this is in a separate file.
//note =>partial. There's nothing in this class
}
public class Person_Validation//the validations go here.
{
[StringLength(255, ErrorMessage="Name is required"), Required]
[DisplayName("Name")]
public string Name { get; set; }
}
first of all here is my situation. I am programming an intranet application using ASP.NET MVC 3 with Entity Framework 4.1. My application has been developed using the "Unit of Work" and "Repository" design patterns.
How ever in my opinion it should go the way that my application has an unit of work that provides a central access to all the repositories which further provide access to the entities.
Lets say I have a entity called "ProductApprovalDocument" with the properties "id", "creationDate" and "approvalDecission" stored in the database. Now I want the user to be able to access a PDF file of the document thats shortly described by the entity. Because the files are stored in a central directory on a file server using the URL format "[fileServerDirectoryPath]/[ProductApprovalDocument.id].pdf", I do not want to save an extra property for that filepath on the database. What I would like to do, is give the entity an extra property called "filepath" that automatically constructs the path with the given information and returns it.
Now the Problem:
I use an interface called FileService to abstract file access from the rest of the application. Now in my case I would have to access the UnitOfWork object out of the entity model, to retrieve the current FileService implementetion and get the preconfigured filepath. I think that's the totaly wrong way because to me an entity model should only be used as a data container not more or less.
Now the Question:
How do I handle such a situation. I would not like to always set the filepath property through the controller because ist more or less static and therefore could be done somehow automatic by the model.
Edit (final solution):
Thanks to the answer of Andre Loker I gained another point of view to my problem.
What was the central target I wanted to reach?
I wanted the user to gain access to a file stored on a fileserver.
Do I have to provide every displayed entity with the total filepath?
No! Think about the principle of MVC! User actions get processed by the controller just in time. You don't have to provide information untill it really get's used.
So the solution is just to render all data as usual but instead of displaying a static html link to the files, you have to include an ActionLink to the Controller which calculates the filepath on the fly and automatically redirects the user to the file.
In the View do this:
#Html.ActionLink(Model.ID.ToString(), "ShowProductApprovalDocumentFile", "ProductApprovalDocument", new { ProductApprovalDocumentID = Model.ID }, null)
instead of this:
#Model.ID
And add an corresponding Action to the controller:
public ActionResult ShowProductApprovalDocumentFile(int ProductApprovalDocumentID )
{
return Redirect(_unitOfWork.FileService.GetFilePathForProductApprovalDocument(ProductApprovalDocumentID));
}
Thanks to the guys that took the time to give me an answer and special thanks to Andre who lead me to the satisfying answer! :)
If I understand the property correctly, there are several options:
1) Make the FilePath property use a service locator to find the FileService:
public string FilePath {
get {
FileService fileService = DependencyResolver.Current.GetService<FileService>();
return fileService.GetFilePathForDocument(this);
}
}
While I'm not a hugh fan of static service locators as they make testing more difficult, this could be a viable option. To make it more easily testable you can make the file service locator injectable:
private static readonly Func<FileService> defaultFileServiceLocator = ()=>DependencyResolver.Current.GetService<FileService>():
private Func<FileService> fileServiceLocator = defaultFileServiceLocator;
public Func<FileService> FileServiceLocator {
get { return fileServiceLocator; }
set { fileServiceLocator = value ?? defaultFileServiceLocator; }
}
And then use this in FilePath
public string FilePath {
get {
FileService fileService = fileServiceLocator();
return fileService.GetFilePathForDocument(this);
}
}
This way you can inject your own file service locator during testing.
2) Explicitly require the FileService when retrieving the file path. Instead of a FilePath property you'd have:
public string GetFilePath(FileService service){
service.GetFilePathForDocument(this);
}
The problem with this is of course that now the caller of GetFilePath needs to have a FileService. This isn't much of a problem for controllers, because if you use an IoC you can inject a FileService into the controller constructor. This approach is the cleaner one as it doesn't depend on service locators, but as you see it is slightly more inconvenient for the caller.
3) Inject the FileService into the document class itself.
Instead of using a file service locator you'd inject the file service itself when you construct your ProductApprovalDocument. With this approach you can use a simple FilePath property again. The main problem is that this often doesn't play too well with ORMs, as they often construct the objects using a default constructor and you'd have to somehow hook into the object construction process to inject the dependencies. Also, I'm not a big fan of injection services into domain objects.
4) You set the FilePath from outside the entity. As you said this should be done somewhat automatically as you don't want to do it manually every time. This would require some layer through which all entities need to pass which sets up the FilePath property.
5) Don't make FilePath a property of ProductApprovalDocument at all. This would be a reasonable choice, too. ProductApprovalDocument doesn't know anything about its FilePath, so why should it be a property? Its the FileService that calculates the value. You can still have a distinct view model version of ProductApprovalDocument which does have a FilePath property. You'd set the property when you create your view model:
var model = new ProductApprovalDocumentViewModel();
mapper.Map(realDocument, model); // map common properties with AutoMapper or so
model.FilePath = fileService.GetFilePathForDocument(realDocument);
However, if ProductApprovalDocument needs to do something with its FilePath (why would it?) this approach doesn't work anymore.
Personally I'd go with solution 5, 2 or 1 in that order of precedence, where applicable.
Whilst I would be hesitant to rely on being able to calculate the filepath and I would prefer to store it as part of the entity (in case it ever needs to change for some reason), in your situation if I was adamant I wanted to do it the way you've said, I think I would extend the FileService/ViewModel to have a Filepath property which was derived in the fashion you have stated.
e.g. if I wanted to create a download link I'd do this in the ViewModel
public string FilePath
{
get
{
return String.Format(#"thehardcodedbit{0}.pdf",ID);
}
}
EDIT: If you have an Entity generated by EF4.x then it will have been generated as a partial class so you could always extend it like this (I have done this sort of thing and it works okay):
Say the generated entity looks like this:
Namespace Da_Wolf.Model.Entities.File
{
public partial class UploadedFile
{....}
}
Then you could create a partial class like this:
Namespace Da_Wolf.Model.Entities.File
{
public partial class UploadedFile
{
public string FilePath
{
get
{
return String.Format(#"thehardcodedbit{0}.pdf",ID);
}
}
}
}
Now you have the property you desire available everywhere without adding anything to the ViewModels.
Im developing an MVC 3 application with Entity Framework and Im tring to use Scaffolding.
To solve "Type not mappedd issue" I've done the procedure found here. Everything now works fine.
Default validation is not working, required field are firing an exception instead of write something on ValidationSummary, so I want to add my custom validations using attributes.
The problem is that the solution about "type not mapped issue" has added 2 .tt files and a .cs file for each of my entities, these files are recreated each time my model (.edmx) is changed and saved so I cant put my Data Annotation Validator Attributes in those classes and either I cant create a new partial class with some properties because thay are already defined.
How can I do? May I have to move validation client-side using jquery? Or maybe there a workaround to add Data Annotation Validator Attributes to my entities, I prefer this way to have more visibility of my validations.
Thanks in advance
I've not used the DbContext generator, but have had similar issues with the POCO Generator. Assuming that the solution is similar:
Modify the T4 template that creates the entity classes to add an extra attribute to the class:
[MetadataType(typeof(CustomerMetaData))]
where "Customer" is the name of the entity.
Then, manually create MetaData classes for each of your entities. You can actually use a T4 template for that, too, if you want, but not have it run all the time.
The Metadata classes look like this...
public class CustomerMetaData
{
[StringLength(150, ErrorMessage="Maximum length is 150 characters.")]
[Required(ErrorMessage="CustomerName is required.")]
public virtual string CustomerName
{
get;
set;
}
public virtual Nullable<int> Type
{
get;
set;
}
// ... etc ...
}
As you can see, you attach the rules to the MetaData class, thus abstracting it from the generated entity class.
on ScottGu's Blog is an Example how to use MVC2 Custom Validation with EF4:
http://weblogs.asp.net/scottgu/archive/2010/01/15/asp-net-mvc-2-model-validation.aspx
So here the Problem:
When the Designer in VS2010 creates the Objects for the DB, along to the example you have to add [MetadataType(typeof(Person_validation))] Annotation to that class.
But when i change anything in the Designer all these Annotations are lost.
Is it possible to keep self made changes to the edmx file, or is there any better way of applying System.ComponentModel.DataAnnotations to the generated Entities?
Thanks.
You do it with a pattern loosely called "buddy classes". Basically what you do is create a separate class with your metadata, and create a partial class that couples the generated entities to your buddy class.
For a simple example, let's say you have a Person entity, and you want to set the FirstName property to be required. This is what you'd do outside of your generated files:
[MedadataType(typeof(PersonMetadata))]
partial class Person { } // the other part is generated by EF4
public class PersonMetadata
{
// All attributes here will be merged into the generated class,
// thanks to the partial class above. Just apply attributes as usual.
[Required]
public string FirstName { get; set; }
}
You can find more details on this approach here. And ScottGu actually talks about it too, in the article you linked to. Look under the headline "Step 5: Persisting to a database" ;)
I am working on an ASP.NET MVC based CMS that presents a rather extreme case. The system must allow the user to add custom content types based on different fields, and for every field, one can add options and validations. The thing is that everything is stored in a complex DB and extracted at runtime using LINQ.
I am pretty fresh with ASP>NET MVC so the following dilemma came to mind
How should I make the content creation view so that form helpers are not predefined int he view code but are loaded based on the type of the field ? Do I have to create a factory class that checks the value of the type property of the field, and then returns a helper based on that or there's a better way to do it. This one seems pretty rigid to me , because anytime I make a change in the Fieldtypes table, I will have to make sure to create a check for that new type too.
public class CType {
string Name; //e.g Post Article etc
List<ContentData> data ;
...
}
public class ContentData {
string Data; // Basically this is the data stored for each field
FieldInstance fieldInstance;
...
}
public class FieldInstance {
string Title; // e.g Title Body etc.
FieldType Type ; // e.g textbox textarea image checkbox etc
...
}
public class FieldType {
string Type; // e.g textbox textarea image checkbox etc
...
}
I see an HTML Helper in your future. The HTML Helper can work through your Model at runtime and output the appropriate HTML for the View. If you go that route, I suggest you get to know the StringBuilder and TagBuilder classes. They'll simplify things and help make your HTML Helper much more readable.
I did not know about the concept of templated helpers. This is what happens when you're new to something. Pretty much, this is what fixed my problem
http://msdn.microsoft.com/en-us/library/ee308450%28VS.100,printer%29.aspx