I have a WP7 project, which will invoke a REST web service in Azure (MVC4 WebApi).
My WP7 project has models that it serializes to JSON and then sends to the web service.
The web service deserializes the data sent from WP7 and instantiates the models again before saving them to Azure Table Storage.
How can I share the Model classes between the projects? Right now I'm just copying the cs files over, and I have to update both sets if I make a change to the models. I was hoping a simple class library project would be able to be referenced from both projects, but WP7 couldn't handle that.
What should I do?
Thanks!
There are many solutions for this issue:
You could use a T4 template to read the entity and generate a class your WP7 project that only contains the properties of the object without reference to the Table Storage specifics (like TableStorageEntity): http://weblogs.asp.net/cibrax/archive/2009/03/11/code-generation-with-t4-an-entities-to-dto-example.aspx
You could split your entity over 2 files, one with the TableStorage specifics like TableStorageEntity and one file containing only the properties of the entity (use partial classes for this). Then you can add the file containing only the properties in your WP7 project as a link.
Create a DTO (or whatever you call it) class manually and use something like AutoMapper to map between the DTO and the TableStorage entity. Store the DTO in a portable library so it can be used by every kind of project. In my opinion this is the best solution since you don't want to completely expose your entities to "the outside world". An example would be a list of users. You wouldn't want to return all fields including password, hash... and other sensitive info. It would be better to have a separate class that only contains the info you want to expose externally.
Related
I've create two MVC and Web API .Net Core projects in one solution, in first project i've added model Phone and DataContext for it, made migration and update-database. In second project i've added equals connectionstring,model and DataContext, but when i try make the update-database i get the next error:
There is already an object named 'Phones' in the database.
Tell me please the right way how to configure database, datacontext and models in two projects to use one database ?
If you use two separate DbContexts, each with their own migrations, they'll consider the database to be theirs and reapply the changes that the other project already did, resulting in conflicts such as the one you observed.
Simply move the Entity Framework code into a shared class library and reference that library from both implementing projects, so all state about the database is shared.
I'd just like to get some clarification in the MVC pattern as to what belongs in Models, specifically the contents of the Models folder in MVC3, versus repositories and objects.
Right now, in my current MVC3 Solution, I have 4 projects:
A Project called "Objects", which holds information about all the core objects in my application.
A Project called "Data" which holds information information about the Data Context and repositories for each of the objects (created using MVC3 scaffolding)
The Web project, which holds the Controllers, Views, and -- the subject of this question -- Models
A Unit Testing project
What I really would like to get clarification about is the difference between what should go in the Objects project vs. what goes in the Models folder of the web project. Right now I'm only using the Models folder for holding what I'd call "View Models", which typically contain combinations of the core objects. Should the files in this folder only contain definitions defining the model contents, or should it contain other code that the controller may call?
I think that I have a pretty good understanding of both controllers and repositories, but sometimes I get confused as to whether certain code should go in one or the other. Are there any specific guidelines or limitations out there as to what absolutely should NOT go in a controller but should go in either a repository or a model instead?
Thanks as always.
We do something very similar except that the Objects and Data are combined in a Core library which is referenced by all projects. The models folder in the MVC project is strictly for View Models.
If your controller require additional classes, it really depends on what it needs as to where it goes. I will typically include a Helpers folder with subfolders for HtmlHelpers, Attributes and Filters. If it's a dependency that makes sense to exist outside the MVC project (common classes which are used across all projects) I'll add it to Core.
I am currently using EF 4 with my ASP.NET Website to access a MySql database. This works fine. However I now want another Web Site project to access the same entities. How do I set this up?
I can't just reference the original website as it's a Web Site, not a Web Application. So presumably, I need to put the Entity Data Model in its own project and compile to a DLL. But...
Which project type?
Do I just cut and paste the DataModel.edmx and DataModel.Designer.cs, compile and add a reference in both websites? What about namespaces?
Where do I put the connection string? At the moment it's in my project's Web.config.
I really have no idea where to begin - I've just followed tutorials to get EF working up to now! I'd really appreciate step-by-step instructions if anyone has time. Thanks.
The model should be placed in a new class library project. My preference would be to recreate the model at this point based on the existing model. For the namespace I like to use {CompanyName}.DataAccess. Remove the old model from your web site project, add a reference to the new class library project and build the web site project. The website project will break in many places, but it should be a simple matter of changing the namespace to the new data access assembly. I prefer this method as to cut/paste because now you have nice clean namespaces. Be careful of any places you may have strings with entity names in them, like if you were using Include (if you are using EF 4 and lazy loading, this should not be a problem). Leave the connection string in web.config for both of the web site projects. When you create the model in the class library, it will add a connection string in app.config. That is OK, it is just there so the model knows how to connect to the database when you refresh it.
General question, when do people access their DAL in a prism application?
That is to say, if a module requires data do you query the DAL on the module load (I've currently been using OnImportsSatisfiedandINavigationAware.OnNavigatedTo` (passing in a parameter from the previous view).
Obviously I wouldn't want different modules to be tightly coupled but for an example where I have multiple views in a module would it be better from the UI responsiveness point of view to retrieve the data up front and pass it into the new view?
Anyone got any thoughts on this that they could share? Thanks.
In my current project we build the application this way that all view models asynchronouls query their data from one wcf service proxy after their own initialization. The proxy itself queries them from the server and caches it internally. Thus you have to think about a caching strategy.
But this leads to the following behaviour: The user interface is build up by the region manager. At the beginning it is empty. After a short time the data arrives from the server, the view models get their model, read the data from it, the data context of the view (which is the view model) is filled up and so the view is populated.
The answer to your question is: The view model queries the DAL (in my case the wcf service proxy) after it's creation in asynchronous way.
I continue with a MVC Web App, and now I'm between the concepts of DRY (dont repeat yourself) and decoupling (be independent).
I divided my big Web Site in diferent projects within a Solution, and as you may already know in MVC the Validations are done in the Model or Service Layer, that in my case its in a diferent project than the one holding the App_GLobalResources, and here is the thing:
How can i access the GLobalResources from a different project, so I can access the strings to set the errors on the model in the service layer?
So far i created a new project like stand-alone resx files and complied them to set the reference to the DLL but it doesnt work, because the main resx files are internals or privates.
I tried one of those custom tools to make resx files public (cross assembly avaiblable) but it didn't work either, because it throws:
No matching culture found
The best aproach so far is to create a resx file just for the Model Project and it works good, but I'm repeating the same strings twice, one for the Views (to set the jQuery string validation errors on client side) and another one for the Model Validations (server side), these give me the benefit of decoupling, but what happen with DRY in this case?
Any advise or tips?
Well i have decided to follow two separetes resx (for strings), one for the Views & Controllers and another for the Model->Service layer, Im using a service layer for validation, so i isolate that layer, in that way i can reuse the layer "Service" or (BLL), in a way that i can reuse it later in somthing like a WPF app, with out any reference to the resx of the Views or Controller. SO decoupling won here ... =)