What could be the best approach to write DataAnnotations and not losing them when the Domain Service has to be regenerated?
What I do is to have a copy of the DomainServise.matadata.cs file, then if I regenerate the Domain Service, I take those annotations back from the copy. Is there a better way?
DataAnnotations attributes are usually copied from your entity defined server side to the entity generated client side. (it's also possible to inject those attribute through a custom metadata provider, so that you don't add dependencies to your model, in my blog I've done it with nhibernate)
Take a look at this tutorial, and see if it fit your needs.
There was also sample from Microsoft on how to create a custom WCF Metadataprovider based on xml file, and I have bookmarked it at his address : http://code.msdn.microsoft.com/RiaServices/Release/ProjectReleases.aspx?ReleaseId=2659 but the link seems no longer active, if this is rather what you needs I can try to find it on my backup hard disk ;)
Finally, take also a look at WCF RIA services domain service metadata, ther's a sample that use partial class, the wcf ria services default way (though you have to add dependency to system.servicemodel assembly for some attributes)
Related
We've started considering using BreezeSharp as we have a WebAPI ODATA Service that we'd like to re-use with a ASP.NET site (no javascript involved, just pure C#).
Unfortunately, we just noticed that, according to the documentation, all of our model entities should now inherit from Breeze.Sharp.BaseEntity. That's a no go for us as this would mean having a dependency on Breeze in our business model. We'd rather keep this dependency on the WebAPI service only.
Is there anyway we could avoid this ? Having proxy classes on the client-side for instance when they don't inherit from BaseEntity ?
Any thoughts on this ?
The Breeze.Sharp.BaseEntity requirement is purely on the client side, and the reason for it is to provide all of the persistence, navigation, key-fixup, change tracking and notification and other services that make the breeze client so easy to use.
There is an IEntity interface that Breeze.Sharp.BaseEntity implements and you are free to implement it instead of using the Breeze.Sharp.BaseEntity, however, this is a very nontrivial task. We are considering offering some guidance on this at a later date if our community generally finds it desirable.
We are also planning on releasing an AOP implementation of IEntity that can be injected directly on top of POCO model objects, but this is likely to require PostSharp and may also have issues running on some client platforms (Xamarin for Android/IOS). No timeframe for this until we get a sense of the demand.
The current implementation on the other hand is very respectful of your model objects, there is only a single 'EntityAspect' property added to your model along with several events.
We have tried the pure POCO approach in the past, on numerous other platforms and application libs and have found that the disadvantages outweigh the minimal cost of a base class, especially when considering that we wanted this library to run in any .NET client including Xamarin/Mono.
If I understand correctly, your only concern is that you don't want to refer to breeze# libraries in your server model. Apparently you have no issue with close coupling of your client and server entity classes in the sense that they have identical properties and perhaps shared methods as well. I'm not being judgmental; I'm merely trying to confirm your architectural decisions.
Have you considered partial classes?
You define the partial class w/o breeze in your server-side business model project and link to that class source in your client model project ... where you keep the companion partial class with the client-specific functionality. That client partial class file specifies the breeze# base class.
While you are at it, you can segregate server-only logic in partial class files that reside in your server project but not in your client project.
Such source file linking has become even easier with VS now that Microsoft is promoting it in their vision of "Universal apps".
I've been reading various other questions about using asp.net-identity but I don't see anything concrete with regards to using it with an existing database when the project is developed in tiers. For argument's sake, say the following is true:
Solution
WebUI
Services
UserService
Data
MyDbContext
Core
User
How can I specify User (from the Core project) to be the IUserStore for the new identity provider? Am I missing something, or does this all assume that the website and the membership database always reside in the same project(or there are strict references to the Microsoft.AspNet.Identity.* libraries wherever the models reside)?
Setting up a DbContext at the WebUI layer just for authentication (and tie it in to the "MyDbContext" with a service) seems hacky. Am i missing something, or was the team just planning on this being only used in simple applications?
And feedback would be appreciated.
More Information
if it's worth mentioning:
This would be a completely new solution; I do not have old/existing aspnet_* or webpages_* tables to worry about. I'm trying to take various other custom solutions and tie them in to one solid solution, so I'm open to a lot of options. However, I would like to keep things broken out by layer (if at all possible).
Asp.net Identity Framework is set of components helping application to work with User Identity. Core framework blocks are in Microsoft.AspNet.Identity.Core assembly. The second Microsoft.AspNet.Identity.EntityFramework is the data persistence implementation for the Core framework.
Now for the n-tier application, you can define your AppUser model in any project/assembly. You need to inherit it from the Microsoft.AspNet.Identity.EntityFramework.IdentityUser. So based on your approach, you need to reference particular assembly.
Same is for the MyDbContext. You must inherit from the currently only available Persistence Microsoft.AspNet.Identity.EntityFramework.IdentityDbContext<TUser>. Your MyDbContext can be in other project/assembly. You need to refer to your AppUser assembly too in this project/assembly.
Problem Background
I'm building a custom WCF Data Service provider using the Alex James set of posts as a basis. My provider works with un-typed entities and sits on top of our own ORM Entity definition framework.
Although I've had a lot of success covering all of the main requirements we've got, I've hit a wall when it comes to defining auto-generated properties in the exposed $metadata page. (The $metadata page is automatically generated by .NET Framework from the internal representation of the metadata - I don't define the document content directly).
Examining the $metadata page for a standard WCF Data Service on top of a simple EF model, you get something like:
<Property Name="ID" Type="Edm.Int16" Nullable="false" p8:StoreGeneratedPattern="Identity"/>
with the StoreGeneratedPattern attribute letting the consumers know about the auto-generation for the given field.
The Specific Problem
My problem is that, in my custom un-typed world, I can't get find the hook to get the StoreGeneratedPattern attribute into my metadata. I'm looking around IDataServiceMetadataProvider and the System.Data.Services.* namespaces but I'm completely stumped.
There is no way currently to specify custom annotations with untyped providers in WCF data services. This is a known feature that is getting asked by a lot of customers. Here's the list to the voting site where you can vote for your favorite feature: http://data.uservoice.com/forums/72027-wcf-data-services-feature-suggestions
Thanks
Pratik
Consider an ASP.NET MVC 2 web application project that uses EF4 POCO entities and the repository pattern to store information in a SQL Server database. So far there are 3 projects, 4 if you count the database:
1.) Domain.dll, has no dependencies, exposes POCO's and repository interfaces.
2.) Storage.dll, depends on Domain, implements repository interfaces (using EF 4).
3.) Mvc.dll, depends on both #1 and #2, provides UI layer.
4.) SQL Server database + connection, dll agnostic (no dependencies).
Let's say I add another web application to host a WCF Data Service, which provides an OData feed of the database using Domain.dll and Storage.dll:
5.) Provider.dll, depends on Domain & Storage, provides OData service layer.
Where does the domain validation logic belong in this solution? If the domain POCO classes are decorated with validation attributes, does the WCF data service need anything else to protect the data? Is it ever a good/bad idea to put validation logic into stored procedures, and why?
I would say put DataAttributes on the Domain and use the validation in MVC for the MVC part and use Ent Lib to do the validation in the WCF Service. Alternatively you could use the Ent Live validation in both MVC and WCF, but thats not what this is about. I dont know that this needs to come down to DDD semantics. MVC does validation on the Models when they have DataAttributes, so follow that and do the same in WCF.
I marked this as subjective and argumentative because even the DDD community can't make up its mind about this.
How many layers do you need to change if a new validation requirement for Customer.LastName comes in? Can the UI layer inform the user the domain, wcf, web, database layers have rejected their commands? How is a LastName restriction that a LastName can't exceed 50 characters part of the business domain?
You can see that this is really a discussion and not a answerable question.
Also if your using OData as a Database feed for your services you are not using DDD. You are using Persistance-As-Model or DDD-Lite. This is actually harmful and results in questions like this that try to resolve the problems with using two incompatible patterns together.
I have an architectural question. We have many applications in our company and we are planning to use ASP.NET MVC and Entity Framework in our future projects. The next project that we need to implement is a central authorization/authentication system. There is no option to use an existing one for reasons that doesn't mater right now. This system probably will be structured as a service. What we don't know is: how the other applications will know about "the model" of this authorization/authentication system? I mean, how they will know user, roles, etc. classes? What is the best practice? One of our colleagues suggested to create the entity framework model (.edmx) in a class library. The problem is that in this case we should copy this dll for all projects that will access the authorization/authentication system. Is it a good solution? Does anybody has a better idea?
You can implement your service as a SOAP-based web service, which means your data model and methods will be exposed via SOAP and described using WSDL. The web service can be consumed from any language, without requiring you to distribute any class libraries.
Many languages also have tools which auto-generate client side class wrappers based on WSDL description of your SOAP interface (e.g. wsdl.exe for .NET clients).
Just to add to what DSO already said, the standard way to do this is through the "Add Sevice Reference" dialog box in Visual Studio. It will query your web service, figure out the classes that are needed, and put them in a reference.cs file. You can also use the svcutil.exe (or if you're using Silverlight, SLSvcUtil.exe) to do the same thing. You have to regenerate the reference.cs file every time you change the interface of your web service, but that usually only takes a few seconds.
It's also possible to create a distinct set of Data Transfer Objects that can be shared back-and-forth between the various layers of your application, but unless you have very strong architectural requirements, I've found the auto-generated classes to work reasonably well.
See also this article here about the self-tracking entities available in EF 4.0, if that's an option for you: http://msdn.microsoft.com/en-us/magazine/ee335715.aspx.