I have two entity models hooked up to two different databases. However, the two databases both have a table named 'brand', for example. As such, there is a naming conflict in my models. Now, I've been able to add a namespace to each model, via Custom Tool Namespace in the model's properties, but the generated code in my Silverlight project will try to use both namespaces, and come up with this,
Imports MyProject.ModelA
Imports MyProject.ModelB
Public ReadOnly Property brands() As EntitySet(Of brand)
Get
Return MyBase.EntityContainer.GetEntitySet(Of brand)
End Get
End Property
giving me this exception:
'Error 1 'brand' is ambiguous, imported from the namespaces or types 'MyProject.ModelA,MyProject.ModelB'.
Has anyone had experience with naming conflicts like this using RIA services? How did you solve it?
Found the solution.
Unload the client (Silverlight) project.
Right click the unloaded project and edit the .csproj or .vbproj file.
Add <RiaClientUseFullTypeNames>true</RiaClientUseFullTypeNames> inside the <PropertyGroup> tag
Reload project. Do a full rebuild.
Now the generated code will use full type names (i.e., MyProject.ModelA.brand)
Related
We have a product which acts as a base framework for other applications/teams.
I am declaring type mappings through unity configuration. On the other hand, every configured module has its IModule implementation in which we map a view with predefined region.
However, to achieve this, every other 'module' project team has to write its IModule implementation and do 'region mapping/registration' themselves in the code.
Is it somehow possible for every module to tell my base product that it wants to register X, Y, Z types/instances through unity "configuration"? My base framework will resolve types/instances and do appropriate mappings. It will allow module teams to focus just on their WPF business views instead of implementing IModule etc.
At present, type mapping is possible in unity but I cannot associate registration with the Prism module. Further, it's not possible to map a resolved type with the predefined region.
E.g. In our application Shell we have a region named 'BusinessRegion'. We have an interface called IBusinessView. Every module will have several business views. Depending on module & its workflow, we have to navigate from one business view to another. However, at present I cannot know which business view belongs to which module.
The same question is already answered in the following CodePlex forum site:
Can we do WPF view-region mapping & interface-type mappings in the configuration?
As commented at CodePlex's, there wouldn't be possible to know which View belongs to each Module after they are initialized. Views and components get registered in the Container and Regions, loosing any dependency reference with the Module.
Regards.
I am very new to WPF.
I am trying to figure out pros/cons of various architecture patterns in WPF, while creating an application designed to interact with a database.
The application begins with a master window, which contains various buttons which load other windows which each perform CRUD operations on different tables within that DB.
I am wondering about the merits and disadvantages of 3 possible approaches:
1) Instantiate a new entity instance within the constructor for each window
2) Each window have a have a constructor which supports dependency injection of the entity object. Every time the master window instantiates a new window object, it injects its own instance of the entity.
3) As per WPF Data Binding Walkthrough Create public ObjectResult properties on a class which inherits from application, and link to this/these properties in the
<Window.Resources><CollectionViewSource>
Tag of the various windows.
Thanks
Dependency Injection is the best option giving you most flexibility...
However, you shouldn't inject something as specific as the entity object but some service provider instead which would be a specific implementation of a service Interface and would not use the entity object directly but a Model instead which would abstract away the data access specifics giving you loose coupling benefits...
I have a VS11 beta WPF application with a Microsoft Datagrid based on a table from an Entity Framework 5.0b2 model (from an sql server database). (The grid uses whatever code was autogenerated by adding a data source from an entity framework model and dragging and dropping a table from that model to the design surface.). I then used the EF5.0 DBContext code generator add-in to generate DbContext types that I could use in the app.
The result was not good. I got a compile error that seems unfixable; at least my attempts made things worse. The datagrid does not like DbContext and doesn't co-exist with it (when both the datagrid and DbContext are based on the same database and tables). Is there a workaround, maybe by changing the code generator template?
The error message is pasted at the end. Thanks for any help or insight on this.
(note the following closely related post isn't an answer because though I can convert dbcontext to objectcontext, I can't get datagrid to work properly with it when I do; and if I convert objectcontext to dbcontext, I don't have the autogenerated dbcontext types:
Convert DBContext to ObjectContext for use with GridView). I'm looking for a fairly simple workaround--I'm sure there's a workaround if I start hand coding all types and conversions, but I want to keep the ease of using the autogenerated code--I don't want to be occupied with work the code generator can, and so should, do. If there isn't a solution, I suppose I'll base the controls on ado.net and leave entity framework for non-ui code.
Error
Cannot implicitly convert type
'System.Data.Entity.DbSet' to
'System.Data.Objects.ObjectQuery'
Documents\Visual Studio 11\Projects\WpfApplication3\WpfApplication3\MainWindow.xaml.cs
The line that caused the error (created by Microsoft drag and drop of the datagrid with an EF table as the source):
System.Data.Objects.ObjectQuery myTblsQuery = myDbsEntities.MyTbls;
The code gnerated by drag and drop in the WPF designer was never very good and the WPF team haven't updated it to work with DbContext. Your best bet is either to drop down to ObjectContext like the other answers suggest or to use the much better WPF data binding supported by DbContext but do so without using drag-and-drop.
WPF data binding with DbContext is pretty easy because the Local property of each DbSet is actually an ObservableCollection which WPF naturally binds to very well. So for example you end up binding your view sources something like this:
categoryViewSource.Source = _context.Categories.Local;
This blog post contains more details: http://blogs.msdn.com/b/adonet/archive/2011/03/14/10138486.aspx
I have a [appname].[ui] project that exists separate from my main silverlight 4 application. I do need to be able to bind to the WebContext.Current.User object in one of those controls and I don't know how to get an instance of it since it is in the Generated_Code hidden folder in the [application].web.g.cs file.
any ideas?
Create a RIA Services Class Library project containing the WebContext class.
Other client side projects can reference that class library project.
for instructions on how to structure your solution, you can refer here.
I am uisng Silverlight 3 and ADO.NET Data Services with a cusotm-built Model (separate project) and DAL (separate project)) in place. Within my Silverlight project, I create a [Service Reference] that references my .svc file that in turn points to my Model.
Here's my question: I would like to use the rich features of DataAnnotations (System.ComponentModel.DataAnnotations) but where exactly do I put these attributes? If I decorate by Model with these annotations, I don't see them rendered in my [Service Reference]-generated proxy code. I just see my classes with its members, but no DataAnnotations (Reference.cs).
I know if I manually change the (Reference.cs) file and add some DataAnnotations, these changes to trickle throught to my Silverlight Client. I don't believe I should be updating generated code, i.e. proxy code w/in (Reference.cs). So, my question is, where in my Visual Studio structure of separated projects (Web, SL, Model, DAL), do I throw/extend this custom datasource (Model) to utilize DataAnnotations?
I would like something like this:
[Required]
public string FirstName
{
get
{
return this._FirstName;
}
set
{
this.OnFirstNameChanging(value);
this._FirstName = value;
this.OnFirstNameChanged();
}
}
I have a replacement code gen for producing ADO.NET Data Service proxy classes and adding in the validation automatically in my Niagara Project:
http://niagara.codeplex.com
I think checking this article out might give you some insight as to why Shawn posted his comment. The short answer to your question is. Follow the ModelView-View-Model (MVVM), style of silverlight development, then place DataAnnotations on the properties in your Model, its a huge topic and you need to read and understand it first. I suggest you check out RIA services,(i think its know as WCF services now), that will help you out alot if you want to propagate Validation logic from the WCF service, back to the client.