Is there a custom implementation for ASP.NET Identity 2.0 that does not use Entity Framework? I'm hoping for something that does not use a full blown ORM but something along the lines of Dapper. The reason I'm asking is because I am not using Entity Framework anywhere else in the project so I would like to stay away from it if possible.
I know I could work on my own implementation but I do not have the extra time to spend on that.
Frustration and lack of other options forced me to do it myself. Here is the project page on GitHub: https://github.com/ryanrodemoyer/AltProvidersForAspNetIdentity2. It's a ways off from a tested usable project but it's a starting point.
Related
We have a ASP.NET Web Api project.
A colleague has removed the Microsoft.AspNET references.
We use IIS web hosting.
I would like to use swagger as api help replacement.
But Swagger or the .NET package Swashbuckle/Swagger comes in the CORE with Microsoft asp.net dependencies.
My colleague said we can not use this swagger.
I would like to know what the real problem is (colleague does not really say...) or what the advantage is of a decoupled web api project with asp.net dependecies?
I mean we host on IIS...
I would like to know what the real problem is (colleague does not
really say...)
Not code but, I think this is the first problem. Try to get your "colleague" to explain "why" it's better. (Not just cool code, but also mem/cpu footprint, team-capability-of-take-over, future path, etc.) Good code is maintainable by any qualified developer, not extremely complex and 'understood by only the one'.
what the advantage is of a decoupled web api project with asp.net
dependecies?
Decoupling is a good thing. First, "if you don't use it, don't reference it". To many projects end up having completely useless coupled libraries. Why? Because the "new project" template had them when the project was first created!
In the specific case of Asp.Net core libraries: The current Asp.Net is old, and a new version is on the way. One that will consolidate the knowledge and techniques of "Asp.Net, MVC, WebAPI, OData, OAuth, etc, etc). https://msdn.microsoft.com/en-us/magazine/dn913182.aspx
This means breaking changes are coming.
Not being coupled to the core libraries that are going to change seems like a good idea. If you want to move to this next version you'll have a lot less problems if you're not relying on 'old Asp.Net' functionality.
My colleague said we can not use this swagger.
I think the better way of saying it is; "We will not use anything that tightly couples us to Asp.Net core libraries again since we're decoupling from it".
We have an app written in Objective C. It uses CoreData, RestKit, about 10 viewcontrollers.
We would like to migrate it to Xamarin (so we can target Android and Windows).
I was hoping there was a way to bind the current code to a Xamarin solution and kind of rewrite features step by step within Xamarin (eg: replacing a viewcontroller at a time, and at the end replacing RestKit+CoreData, by SQLite + ServiceStack).
I am aware of the binding to Objective C option that they provide, however, it doesn't look to be the appropriate fit for this (way too complex, probably easier to rewrite the app from scratch).
Is there a way to migrate our current project to Xamarin so we can convert? or do we start from scratch?
Thanks.
Options:
Migrate full project - no;
Automatically create binding for libraries, rewrite business-code, UI-code - yes;
Rewrite from scratch using .Net/Mono classes - yes.
If code size is relatively small, you should rewrite the whole app. Moreover, thus you could have a chance to separate business-logic from UI code and tools libraries (RestKit, CoreData). In perspective, that code will be more reliable and cross-platformish.
This tool can help. It does Obj-c to C# translation (some manual cleanup required):
Automagical
Quite probably, a re-write, from scratch. One thing to keep in mind, if your back-end is .net.. and you are using DTO's.. like with AutoMapper from Entity Framework objects.. you'll be able to re-use those DTO objects on your mobile side with Xamarin. If you are using OData, I'm not sure if this is still a problem, but Xamarin studio wasn't generating OData service clients. So you had to generate them in Visual Studio, then take the generated client code and throw them into your Mobile projects.
sqllite-net is awesome. I've never had any problems with it.
https://github.com/praeclarum/sqlite-net
I currently have a project, with DTO Objects from an Azure WCF service, that I push directly down into SQLLite objects on IOS and Android with Xamarin. I use RestSharp, rather than Service Stack. I should probably go learn the difference.
If you are looking to use SQLCipher from the Component store, to encrypt your sqllite db locally on your device (Good advice to do so), you should be aware that there is an issue in android.. going to 2.2 or 2.3 with SQLCipher. Works for ICS and above though, if I remember right.
Just be careful on your security implementation for allowing clients to connect. I want to say.. don't take too much advice.. and don't take too little either. : )
I have an existing ASP.NET MVC 4 project that already uses ServiceStack for REST services, and I just read all about ServiceStack.Razor and would love to move the entire project onto ServiceStack. Right now there is only one controller and view besides the built-in AccountController, and that controller just returns the view and the view is really just HTML; everything else is HTML/CSS/JS + ServiceStack REST.
The only real legacy constraint here is that this new app still needs to make use of SimpleMembership. At present I'm using a custom auth provider to authenticate against SimpleMembership and I would like to be able to continue to do so.
So, what would be the best recommended path to achieve this end? Can I get what I want by modifying my existing project by removing some references, or should I start fresh with an empty ASP.NET app and move the old stuff into it? Can I have SimpleMembership without introducing dependencies that will step all over ServiceStack.Razor?
If you were to start a new solution using only servicestack then MVC would never be there to get in the way.
I use servicestack.razor and love it. It is a lot simpler than MVC in my opinion. Moving everything to the new solution is pretty much going to be copy and paste since what you have works. I wouldn't hesitate and would make the move sooner than later. In the end you are not gaining anything from MVC. You only gain using servicestack. A big deal for me is self-hosting and eventually moving to mono.
This is a question that will have answers based off opinion so I suspect you will receive a few. I have not personally performed such a migration so this is only opinion but is how I would approach it. However, my recommended approach would be:
Retain the existing application/ Given its current simplicity, creating a new app and moving existing items into it seems unnecessary.
You should be able to use your existing auth solution via SimpleMembership and use ServiceStack.Razor. I would proceed as such however it does depend on what other ServiceStack features you may use which could cause conflict. A ServiceStack expert could comment more on this. Even if that did occur, you would be able to work around it relatively easy. At worst, implementing a simple handler would get around almost all issues from an authentication perspective.
Working with different razor engines is relatively easy to do and you can use/enable/disable existing or new build engines via a few lines of code. See here for an example. This should alleviate any concerns around dependencies of other built in or custom engines.
Consider looking at ASp.Net 4.5.1/VS 2013 (since your project is in early days) as it has enhanced membership support and is moving to a more "less dependent" model of components via the Owin stack Asp.Net 4.5.1 and VS 2013. Katana is a microsoft project that also provides some Owin based authentication components see here and here which you could use now and this would remove a lot of dependencies and enable you to migrate other framework with relative ease. Downside is that Katana/Owin has a little ramp up time/learning curve. Again, given your project is in its formative days I would recommend looking into Katana and the ASP.Net vNext stuff as this will make it easier for you and means you dont have to migrate to the new version once it is released.
Long time lurker, first time questioner here :)
I have been looking into our company's next software system architecture. We have been using CSLA.net, to some extent, as our business object framework and are thinking of building our new architecture around it. CSLA.net has support for the platforms mentioned in the title and we are looking for mvvm framework that would work well with it.
At the moment we only support windows environments but are also looking to support at least Android and iOS (also mono in general is under consideration). We are looking to share as much of the code as possible between the platforms and MvvmCross seems like really nice piece of mvvm (+) framework, especially in that context. I have watched few n+1 videos and what I have seen so far has been very impressive. I also like the Stuart's style of introducing the framework and concepts around it.
Has anyone tried to build a cross platform application that uses both of these frameworks (CSLA.net and MvvmCross)? If yes, what have been your experiences like? Also if Stuart could comment on the issue of how to merg the viewmodels of the two frameworks. I remember Rocky (Rockford Lhotka) recommending, as a general tip when working with mvvm frameworks, to inherit CSLA.net viewmodelbase(not viewmodel) and implement also mvvm framework's requirements into that class. You can find source of the viewmodelbase from https://github.com/MarimerLLC/csla/blob/master/Source/Csla.Xaml/ViewModelBase.cs.
Any input would be much appreciated.
Regards,
Harri
ps. I think, that this would make a great n+ video. Wouldn't it ;)
I've personally never used CSLA, but I have talked with it's original author, Rocky, both by email and in person.
CSLA presents itself as a business model object layer and that it can very successfully interoperate with independent Mvvm frameworks - see Rocky's post on CSLA+Mvvm
MvvmCross provides the more application and UI level support - and leaves application authors free to choose how they write their business services and models.
Because of this, yes I think it should be possible and even straight-forward to use both of the frameworks together if you want to. To get started, it might be useful to write some prototypes - and perhaps to look at the way other integration has been done - e.g. CSLA+Caliburn integration
ps. I think, that this would make a great n+ video.
I'd much rather see this type of article from someone who understands and uses CSLA. I would encourage all members of the MvvmCross community to contribute their own blog posts, articles, videos and github samples.
One caveat to this advice: I don't know if CSLA support Portable Class Libraries - if it doesn't then you'll probably need to use file-linking rather than PCLs in your app
Yes, you can use a multitude of MVVM frameworks; I've used CaliburnMicro and our own custom MVVM with success. If you haven't checked out Rocky's eBook series, you should definitely do so. One of the big gotchas is the limitations on reflection in Silverlight, hence also in WP8 and WinRT, so some reading up on that is well-advised.
Regarding Portable Class Libraries, you can't those for CSLA business objects (they require more stuff than is available in PCLs), so you do have to do the project linking. Typically, write the complete class in the .NET libary w/ pre-compiler directives, such as
#if !SILVERLIGHT
around code that can't be complied for Silverlight/WP8. I do use PCLs for some basic stuff, like enums and constants, but not for the business classes.
Xamarin have just released some updates that mean the latest framework 4.5 with async features can shortly be implemented...
We have been looking closely at SPAs using Breezejs for providing the data context between the client and the server. The features look great on the client, but we want to use the Repository pattern on the server and get good separation of concerns without having to inherit from EFContextProvider which would cause problems with IoC and possibly unit testing/mocking. We have been following John Papa's Code Camper sample on Pluralsight which initially set out using a Respository/UoW pattern without Breeze which then led us to look at the Hot Towel template which does include Breeze.
Does anyone know how Breeze can be abstracted to a Repository which keeps the DbContext cleanly (if using Entity Framework) encapsulated. Also, what happens if you are not using Entity Framework and prefer to use another ORM such as nHibernate.
Thanks for posting here as I am sure others will ask this :)
If you don't use EF then you won;t get the automatic metadata creation that Breeze provides. You can certainly abstract the EF context into a Repo however, and still get the benefits.
The Breeze/Knockout ASP.NET SPA template shows the repository broken out. I believe there is a sample for the UoW somewhere - tho it escapes me where. I have asked the Breeze folks to point to an answer for that.
If you use nHibernate there is no automatic metadata - however that is a great feature request I could see for Breeze.