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.
Related
Is it be possible to customize/extend JHipster for an organization ?
By that, I mean having a local version that creates some projects with features that are specific to an organization ? For example, using a custom authentication scheme (that still relies on Spring security), using custom styles (colors, fonts), adding certain Maven dependencies and so on.
If this is possible, can it be done while retaining the possibility to update JHipster in such a way that an update of JHipster would not overwrite these extensions ?
Thanks.
Here's the approach in general:
First, we created a blank project with all standard JHipster
stack. DBMS used is Postgres. We outlined the basic data structure
with jhipster entity generation tool, creating the most important
relations etc. We also defined the basic user roles and permissions
within standard JHipster options. At this phase we didn't pay very
much attention to the details such as complex unique constraints,
business restrictions, user management, JPA errors handling and
presentation etc. Just created a sort of backbone to start with.
CRUD pages are all standart.
We introduced some domain-specific business logic. Basic frontend customization was performed: branding,
styles, some custom views (still used bootstrap classes extensively) etc. Jhipster-generated frame was kept in place but extended. We changed authorization logic a little bit on both backend
and frontend, it's token-based with certain token validation
rules. User-friendly error handling was introduced, allowing user to
understand what business restrictions show up in various conditions. We started to write more complex unit tests to meet the business logic implemented recently. Entities are mostly (~80%) crafted manually at this stage, because we got used to the data structure offered by JHipster, and we had too much customization in CRUD REST controllers, pages and tests covering all that. Liquibase changelogs were generated with liquibase:diff and edited manually. We don't add such entities to .jhipster folder.
Because of demands for interface design growing high and strict, it was decided to introduce separate frontend layer for end-user interaction. It partially shares REST interfaces with jhipster-generated frontend, but is absolutely independent in terms of project structure. We decided to use Angular for new frontend layer as well. In fact, it is a subfolder with separate index.html, bower.json, Gruntfile.js etc. At the same time we continued to improve business logic, refine db structure, increase code coverage, introduce new user roles etc.
...
So we have slightly customized "old" JHipster frontend for administration and data mangement purposes. And an independent "new" frontend with custom design to deal with end users. Please note: it IS possible to keep an original interface, customize it to some limit and preserve the possibility to generate entities, and it worked well in our project as far as it was justified.
Some notes:
Component versions in pom.xml were constantly updated by hand;
Maven dependencies were manually added to pom.xml;
JS dependencies were manually added to index.html/bower.json/app.js;
If you have complex frontend scripting, dealing with JS uglification for production profile may be tricky;
Another difficult thing is to keep liquibase scripts working for both DBMS used by spring-boot and H2 which is used for tests;
You'll probably face some problems with configuration tuning depending on domain logic specific for your project.
I hope it helps.
Another approach that has been introduced in release 2.26.0 (mid december 2015) is to build your own modules, see documentation.
Later on in release 5.0.0 (mid 2018), JHipster has introduced a more powerful tool: blueprints, although it requires more effort than creating a module. With a blueprint, you can even replace the language/framework of the generated project, it has been successfully used for Kotlin, NodeJS and VueJS.
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".
I am having a little problem in my workplace where we have a IIS 6 server where Orchard (1.7) will not run. We are planning an upgrade but that's going to take some time.
Since we are using this site on IIS6 only to run one particular custom module we wrote for Orchard (basically a MVC module with its own Controllers/Actions etc.) I was thinking that a temporary solution could be to rip that module out of Orchard and run it independently.
Of course this extraction needs to take into account how many ties I have with the framework. I was wondering if there is some kind of guide to perform this and if there is something I need to take specially into account.
I am using the Users in Orchard so I would probably have to rewrite some users code. I am also using the Authorizer, which again may mean I need to re-wire something else.
It seems like a daunting job so I am looking for some quick tips on how to proceed if you know any.
Thanks a lot!
It all depends on what components you actually use within your module.
Hard to write any tutorial on this, really.
Regarding Orchard.Users - you could drop all related code usages and rely on the default ASP.NET roles-based authentication/authorization model.
If dependency injection is what you want to keep, then you need to integrate it yourself (for Autofac, but other DI containers will also work). Feel free to copy and change any Orchard components that you use, stripping the unneeded code.
In my opinion the hardest thing to strip out and replace would be any code that relies on content items - hope you don't have it. Rewriting this pieces sounds like an overkill. But if you just use IRepository, going for plain NHibernate or EF instead should be quite easy.
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.
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.