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".
Related
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.
Recently I saw this document that specify how great is Caliburn(Not really it compares it to the micro framework, and thats enough).
I'm working with Caliburn for more than a year and don't know many things about it.
So maybe someone can explain the following(Some of it I can understand but have no iea about the relation to caliburn):
Validation abstraction
module framework
ExpressionTree-Based runtime delegate generation
ViewModelFactory
ShellFramework
I'm working with V1.1 so if something is new in 2.0, just say it belong to the new version I'll learn it probably in the future.
The validation abstraction is aimed to plug a validation infrastructure in ViewModels.
Caliburn's DefaultValidator uses System.ComponentModel.DataAnnotations, but an adapter for Fluent Validation is also available.
While the validation could be used directly from application code, it is used by the framework mainly in the AOP validation behavior, which provides an automatic IDataErrorInfo implementation for models.
If your models already implement IDataErrorInfo, Caliburn is able to hook the validation (as a part of conventional binding process) leveraging plain WPF binding.
Yet, implementing IDataErrorInfo manually is boring and likely to lead to hardly mantainable code, so the AOP [ValidateAttribute] was introduced.
To enable it, you have to configure your container to use the available proxy factory (which is based upon Castle.DynamicProxy):
myContainerAdapter
.WithProxyFactory<Caliburn.DynamicProxy.DynamicProxyFactory>()
This instructs the container adapter to inspect behaviors attribute applied on the ViewModels (and other components) pulled from the container, and to create a subclass of them implementing the specified behavior.
The [Validate] behavior implementation just delegates 'IDataErrorInfo' calls to the actual IValidator service.
Module framework is used by Caliburn itself to manage configuration and initialization of its own modules. It could also be used to create independent application modules: Caliburn will take care of discovering them (if their assemblies are registered in IAssemblySource) an drive their initialization;
Caliburn doesn't use reflection to invoke action, but builds delegates on the fly leveraging Expression Trees to create a compiled lambda;
The ViewModelFactory service is used by Caliburn to abstract the creation of VM, either by type or by Subject handled;
ShellFramework contains a set of facility useful to build most applications; it includes some custom IResult (along with fluent-style static methods to create them) and some pre-built ViewModels (Menus and Question/Message dialog) to accomplish common application tasks.
I have an MVC solution setup like this, with three 'projects'.
Web (MVC Project, Views, Controllers, ViewModels)
Models (Domain Objects)
Persistence (nHibernate Mapping, SessionFactory)
I need to begin building the repositories, and was going to start with the Authentication Model. Basically following the default MVC template, have an IMembershipService and an IFormsAuthenticationService and related classes (using custom code, not built in authentication providers).
My question is ...where should this go? My Repositories will need access to both my Domain objects and my Persistence Layer. However I keep reading that any kind of 'coupling' means it is a bad design. So I am hesitant to create a fourth project for the Repositories/Services that references the Models/Persistence ...but I can't really find any other way to do it logically.
This is very subjective.
Do what makes sense to you and your team.
I throw them in with the rest of my Repositories. I mean a User is pretty central to any application right? Does a User own anything? If so then isn't he an root?
Repositories are part of the domain.
Tension will always exist between reducing assembly references and minimizing number of projects. That is, you can make each assembly reference fewer dependencies by breaking up functionality into more fine-grained assemblies; however, excessive division of a project into many assemblies requires more effort to manage.
Another point worth mentioning is that authentication has a couple sides to it. One is managing the model around Users, Roles, Permissions, etc. - this is a domain concern. The other is interfacing with the context of execution (whether this is an ASP.Net app, WinForms, etc.) - this is an infrastructure concern. Consequently, I end up with a small service in my MVC project or WinForms project that performs functions like setting Forms Authentication cookies, or setting the current thread principal, etc.
The Separated interface pattern says that your models and repository interfaces should be in a seperate assembly, apart from the GUI and the actual repository implementation. This is to be able to switch implementations later on and to be able to simplify testing.
I would have no problem with putting the interfaces along with the repository interfaces and the actual implementation in the mvc project or the repository project. It's quite easy to move stuff later on if you use a IoC container.
When I start work on a new web application I tend to reach for the same tried & tested architecture of ASP.NET MVC, BLL (consisting of a set of services that contain all business logic) and a DAL (consisting of a set of repositories that facilitate the unit of work pattern over something like EF/*Linq to SQL*).
The controllers talk only to services, the services only to repositories and other services. At the service layer are where models are defined and these are used as input/output to/from the controllers.
My question is: what are others doing? I'm interested in knowing if people are doing anything different in the context of an ASP.NET MVC web application. For instance, there are concepts like CQRS and Domain Events. Is anyone using these to solve a problem with the method I've described above?
This question is mainly a source of attempting to discover what I don't know I don't know. I hope it's not too vague, but I think it's important to see what others are doing to evaluate your own methods.
We're basically doing what you're doing, except that we consider our repository interfaces to be services (they are defined in the business layer), and therefore our controllers often access them directly. An IoC container takes care of injecting the correct repository implementation via constructor injection. So the data layer depends on the business layer, and is in charge of implementing the repositories, while the business layer just assumes that all the repositories it has defined will be available at runtime.
We've further divided our product up into different modules of functionality. Some of the modules depend on one another (for example, everything depends on our core functionality, and most of the other modules depend on the web portal module), but keeping them in separate dlls helps us to avoid making these modules be too tightly coupled. The system can therefore only load the DLLs for the modules that a given client has paid for. We plan to use an event bus with events defined in the core module to allow the modules to communicate via a publish/subscribe model.
I am using CQRS with MVC. Its nice. You still use the MVC pattern, but in the controller I use the command pattern for the write, and just pure NHibernate Linq for the read... also some SolrNet for the read. :-)
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.