Please advise the modern architecture of ASP.NET WebApi application (better .NET Framework not Core) with the latest innovations. For example: Unit of work pattern, controller -> manager -> repository, Automapper, xUnit, Serilog or..., a reliable migration mechanism for Oracle - Liquibase or... Asynchronous execution - async / await.
Requirements: authentication - AD / Windows, DB - Oracle. If there are code examples it would be ideal
UPDATE 1
What about ORM and migration system. In my opinion code first approach and EF migrations is good because the model suit to DB copletely, but it is risky. Previously I made Database Project for MS Sql Server and all change scripts was generated by comparing schemas of original DB and DB changed by EF migration, like this:
create models
apply migration to local (dev) database
compare original DB and changed DB, ectract/generate change SQL scripts
create deployment migration for CI/CD (DB project, liquibase or similar)
rollback local DB and test deployment migration
commit and push
It looks strange, but practice shows that using EFs migrations leads to data loss
For me, an API (which your app exposes to consumers) can be thought of as just another type of presentation layer.
If you assume that's the case then any sensible .Net architecture would suit. Personally I follow an logical approach like this: 5 layer Architecture - https://morphological.files.wordpress.com/2011/08/5-layer-architecture-draft.pdf
Not sure if that answers your question though. I think if you get the logical architecture sorted out, then determining which technologies you use to implement isn't so hard.
The 5-Layer architecture referenced above uses dependency injection, so you can use whatever database technology you like.
Use of sync vs async depends on the nature of the actual functional and technical problems you're trying to solve.
Related
I have inherited an ASP.NET application, using Entity Framework 6, and have enabled migrations. In my Global.asax, I have this:
using (var context = new MyContext())
{
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContext, MyConfiguration>());
context.Database.Initialize(true);
}
The problem is that every time my application needs to start up (due to IIS shutting it down for example), this logic is run, even though in most cases there is no migration to be performed. This significantly slows down the processing of the requests.
What are my options here? What is best practice? I could disable this and use the Package Manager Console to perform migrations manually, but that kind of beats the purpose (though if there are no other options, I'm prepared to do this).
The EF6 automatic migrations seem to introduce several issues (not only performance), so the EF Core team decided to remove them from EF Core (you can read some reasoning here).
Since EF Core is the EF6 successor (the future of the Entity Framework), looks like the recommendation (best practice) is to disable it and perform migrations manually.
I am wondering some point on deploying an Asp.NET MVC5 application to my own server.
What if it happens, if i add more attributes in one of my model class or add more model class. What should i do for not losing data.
Is there any other options shoul i need to perform other than asp.net mvc4 since i could not find any tutorial about deployin asp.net mvc5 with Identity.
What is the best efficient way to change my application view, controller and model on run-time. Can i working on my local PC while using the remote code file and database ?
Regards.
I have a hard time understanding your requirements but for the database part, I would recommend "entity framework migrations". It's made handling model changes locally and remotely.
http://msdn.microsoft.com/en-us/data/jj554735.aspx
I have worked with entity framework migrations a lot but sometimes if you make big changes, such as Foreign keys or enums, the migrations give a problem. I then started to use a tool from RedGate.com called "Sql Compare." Works better than Entity migrations - now I don't worry about data changes. Usually this will not lose data, but if it is going to lose data, it will warn you.
Best solution to losing data -make backups.
I have the main website that uses a database to store and access user accounts. I'm using EF to manage the schema. I also defined site-specific POCOs and have migrated them to the database.
Now, what if I want a separate website, for example, a resource server (Web API) that would expose (with authorization) the same data set up on the main website?
Do I create the same POCOs and derived DbContext on the resource server again? That seems like duplicating work, though.
What if I wanted to create new POCOs on the resource server and reflect them onto that same database? Wouldn't that conflict with the current migration (which is saved on the database), then subsequently mess up the EF setup on the main website?
I've seen the suggestion of putting the POCOs and DbContexts in a library and have multiple projects reference that same library. This seems viable, however I'd have to hard-code the connection string, which seems dirty to me.
I'm starting to think that EF is probably not recommended for this kind of setup. It seems like a database-first approach plays better here - though I would have to manually reedit the data contexts (most likely, LINQ-SQL) for every database schema change.
Are there any lesser-known capabilities, facts, practices, etc., for/about EF that would help in this situation?
Generally, you can avoid duplication by having one API serving both sites and have resources version for each if needed. On the other hand, if you choose reuse and add approach, creating additional EF code-first entities should not interfere with other site data layer if modeled and mapped carefully. DbContext connection string does not have to be hard-coded.
I'm thinking of using Flyway for my database migration. Seems like it will be simpler than creating my own SQL and Java migration scripts. However, looking at the documentation there seems to be several ways to use it.
What should I consider when deciding between migrating with (a) application integration, (b) a maven task, or (c) the command line?
Currently I deploy to heroku with a simple git push. This builds my app and starts it as specified in the proc file.
So in this regard it seems like the application integration (migrating on startup) would be the simplest. But it also seems like overhead I don't need. I suppose if I do the maven task I would need to ensure that heroku calls maven correctly to make this happen.
What are the trade-offs? Is anyone currently using Spring + JPA + Flyway together with a heroku hosted application?
You are correct, the application integration is the simplest. Code and DB can never get out of sync.
The overhead is absolutely minimal, especially compared to JPA. The few millis it'll cost you on startup are well worth the dev and deployment convenience.
I've got a client who wants an ASP.NET MVC application. I'll develop it with VS.NET 2010 Express, demo it to him on my Linux server during its development (Mono supports ASP.NET MVC), and he'll eventually host it on a commercial provider running IIS.
Getting this done quickly is the name of the game. The only piece I'm missing here is the database layer. Ideally I'd use SQL CE and EF4. But SQL CE only works on Windows, and Mono doesn't support the Entity Framework anyway.
The only free Linq to SQL-like option I see is DbLinq. A quick test with that on a MySQL database had it erroring out on a table that had two foreign keys to a single primary key. A search on Google shows that this bug was identified, and a patch was created, two years ago or so. That the patch still hasn't been applied to the main source by now, and that this bug seems to affect so a common scenario, does not fill me with confidence on the production-readiness of DbLinq.
Even if it did work, it'd have to be with MySQL, as that's the only database I can expect to be available on both Linux and an eventual Windows server. (SQLite, Berkeley DB, etc., would all require some native drivers be installed on the server, which I can't count on.)
I don't know NHibernate. But from what I read, it requires manually creating XML mapping files... so I don't have to write SQL statements, but I do have to create mapping files? (Plus I'd need to learn how to use it.) Like I said above: Getting this done quickly is a goal here.
If I must, I will just pony up the $5 a month or so for a cheap ASP.NET hosting provider and use that to demo progress to the client, using SQL CE and EF4. But before I do that I'd just like to see if there are any other viable options. (It's kind of mostly an intellectual exercise by this point.)
So... any tips?
Does it really have to be a fully bloated ORM?
I recommend to have a look at some of the so called "micro-orm`s", especially my favourite one: Peta-Poco (http://www.toptensoftware.com/petapoco/)
Peta-Poco runs perfectly under mono and has an incredible performance. Even better, because of the small codesize (~1k lines of c#) it is very easy to understand what`s going on under the hood and you can easily change/extend the code to your needs. For the start you just have to copy the single .cs file in your project and you are ready to go.
Peta-Poco has a very well poco-mapping heuristic so you will get your c# objects out of the db with zero configuration for the most cases.
You COULD try Linq-to-SQL. Partially supported under Mono from 2.6, it supports many dbs under mono Release Notes Mono 2.6 (they are working with those of DbLINQ to make it).
Ah... Forget to learn quickly how to use nhibernate. It's very good but it's quite an hell. And creating the XML is the least (and with NHibernate 3.2 they have added their version of Fluent interfaces, so XML aren't anymore necessary I think. You can "code" your XML.)