问题
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 ?
回答1:
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.
回答2:
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".
来源：https://stackoverflow.com/questions/24300209/breeze-why-inheriting-from-breeze-sharp-baseentity