SQL database, in mvc project I use EF to create model classes. One of the classes has two fields related to one field of another class, many-to-one relation. They are named like "Field" and "Field1" in this linked class. Is there a way to rename auto-generated names of these two virtual fields in the class?
EDIT. Or maybe just a conclusion.
It looks like it's a messy topic about linking a database to an asp.net application. There are different approaches and tools and there are ways to abstract from it like partial classes, viewmodels, automappers and all with their own bugs and workarounds... and there is no a comprehensive tutorial on all this stuff explaining what and when and how to use... such a visual development environment... pure easiness.
Related
I'm using the code-first approach (per se) in EF, however, I'm using T4 to generate a class per table, and then creating the associations in a separate partial file. I know I can use the edmx to generate poco's with table-per-type but thats not a route I want to go down.
It appears to work until I have a class name that's the same as another class, even though both classes are in different namespaces.
The solutions I've found seem to solely revolve around fixing the metadata in the connection string, however, since I have no edmx (csdl, ssdl, msl) I'm not sure how to correct the issue. Here's a related question, but the solution doesn't appear to be something that will help me - Can't have the same table names in different entity framework models?
Unfortunately just renaming the class is not a solution for us.
Here's the error:
The mapping of CLR type to EDM type is ambiguous because multiple CLR
types match the EDM type 'AppConfig'. Previously found CLR type
'Utility.AppConfig', newly found CLR type 'Config.AppConfig'.
Apprently this is fixed in EF 6 - for code first only.
I understand that Code First used to have a problem (or maybe still does) when you have two classes with the same name in different namespaces. I have found numerous posts about this. I have something a little... different?
Well, however they "fixed" it, they made it worse. I don't HAVE two classes with the same name, I have ONE class. I promise you, you are not seeing double. The class name that appears below is exactly the same, and there is not other classname.
The mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'Classname'. Previously found CLR type 'App.Domain.Classname', newly found CLR type 'App.Domain.Classname'.
I get this error repeated many times (for different class names) when I attempt to create a new controller with the Template "MVC controller with read/write actions and views, using Entity Framework."
If you are having more than one edmx file in same module this problem will be occur. And even within those edmx it may have same kind of two entity was exist. This is framework issue from ef4. But it can be resolve by.changing the entity name manually.' Which was created by edmx generated. Or simple add one more dump column in any one.of the entity. In first way we should do more changes in all the entity class as well as reference entity class also.
I have a situation where I have a Common.Domain.Person and Specific.Domain.Person.
First one should be provided as a part of a common package.
Second one appears when common package has to be customized to fit the needs of specific project.
In the object model, it can be easily implemented with inheritance.
In the NH mapping, however, I have encountered a small problem.
I can create an NHibernate <subclass> mapping, but that would require me to use an discriminator. However, I know that if specific person class was inherited, then common class instances will never be used within this specific project.
What is the best way to implement this without adding discriminator column to the base class (since there are no different cases to discriminate)?
this is what i wanted and nhibernate supports it using xml entities. Unfortunately this feature has been borked since (at least) NH v2++.
see also Using Doctype in Nhibernate
A work-around could be to inject these properies programmaticaly when you create the SessionFactory (Dynamic Mapping)
see also http://ayende.com/Blog/archive/2008/05/01/Dynamic-Mapping-with-NHibernate.aspx
Just map the Specific.Domain.Person and leave Common.Domain.Person unmapped.
If you are not saving instances of it, NHibernate does not need to know about it.
I have a fairly large application, where my data access strategy has always been quite old school:
I have 4 Stored Procedures per Table: TableName_Select, TableName_Insert, TableName_Update, TableName_Delete.
I have a MsSql#DOMAIN#Service class for each logical domain of my application. In that class I have corresponding method to Select, Insert, Update and Delete something in the database.
I want to maintain my own Model classes in a seperate class library project, along with service contracts for WCF services. That enables me to reference only the naked Models, Service Contracts and WCF Service Clients from e.g. a web app or a windows app. (I don't use the auto-generated WCF Service Clients either)
Can I use my own Model classes along with Linq-to-SQL - or do I have to use the autogenerated Models from Linq-to-SQL and then map them over to my own Models in my data access layer before returning them back through the WCF service?
EF Code First FTW!
You don't have to use the auto-generated types with a Linq To Sql data context, but by default the types that you use need to have all the attribute annotations that you'll see on them.
However, Linq to Sql also supports custom mapping (the default being to use the Attributes), where types are mapped to tables and their properties mapped to columns using a MappingSource which is provided to the DataContext on construction.
L2S comes with two - the AttributeMappingSource (used implicitly) and the XMLMappingSource. It's possible with the second of these that you can hand-crank a Linq To Sql DataContext that exposes EntitySets of your own types.
You could even write your own MappingSource - but I think the XML one probably covers most needs.
We have done something similar in our applications. We wrote our own code generator to generate our L2S classes and also what we call our "application" entities. These are much more lightweight than the L2S classes. They are used at the application level to pass data back and forth to our back-end. Each L2S entity class has a built in application entity equivalent where automatic mapping occurs. What I mean is that whenever a L2S entity has data stored to its properties, the values are automatically copied to the respective application entity property. We then have a method on each L2S entity that allows us to retrieve the associated application entity.
So, the short answer is yes, you can use your own classes in conjunction with the L2S entities.
I try to set-up a clean and flexbible application-framework for data-centric applications with silverlight-only UI. I want to have a strict seperation of concerns, and want to be as flexible as possible (e.g. exchange the ORM later) while still reducing the amount of code.
It took me weeks to figure out an appropriate architecture, and although my latest approach seems to fit my requirements I'm still not completely convinced, that this way will be the best and is technically possible.
Here is how my solutions-explorer looks like:
MyCompany.MyApplication.Entities
Class library - project, which contains only the domain (business) objects, such as Customers, Adresses, etc. These are POCOs with the [Serializable] - attribute, but do not any other code. All properties are marked as virtual, so that classes could derive and overwrite the properties.
MyCompany.MyApplication.DataAccess
Class library - project, which contains the nHibernate - specific code (Sessions) to load, save and delete the domain objects. This project has references to the Entities-project and also to the nHibernate-libraries.
MyCompany.MyApplication.Core
Class library - project, which contains the business logic, and often just maps the methods form the DataAccess - project, such as GetAllCustomers, SaveCustomer, etc.
It has references to the Entities-project and the DataAccess-project.
MyCompany.MyApplication.Web
Web-application - project, which hosts the silverlight-client-app and also the WCF-services to communicate with the client-side. To expose the domain-objects to the client-side, these classes are derived and all the properties are overwritten and marked with the [DataMember] - attribute. It has references to the Entities-projects and the Core-projects.
MyCompandy.MyApplication.Silverlight
Sivlerlight 3.0 - project, which represents the userinterface. It has only service-references to the WCF-Services exposed by the Web-project. The actual domain-objects aren't accesssible, but the auto-generated proxy-classed replace them.
Please tell me, what do you think about this architecture, and if there are any conflicts! Further question: Is there any way, to avoid the properties of the domain-objects being virtual and the need to overwrite them in order to make them accessible trough WCF?
Best regards,
Daniel Lang
Daniel, you are not going to get around the nhiberante requirement of virtual properties. Have you thought about using Dto's?