Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm in charge of porting a Java application to .Net platform.
I'm kinda experienced with C# and .Net but I've never started building things like this from scratch.
So, this application consists of two parts:
Framework: A small framework responsible for creating CRUD pages endpoints. This framework uses classes from the "business layer" as models in order to easy build pages. It basically has a FrameworkPage<T> class and we use a type T and some overridings in order to write it. Also, this framework has some endpoints of its own. Like myapp/framework/FirstPage which maps to a framework/{pageName} controller where we use a generic logic to retrieve data for that page. The important part is that this framework has its own endpoints.
Business Layer: Application that uses the above framework, has its business classes and also has its own custom endpoints for pages that are not the default framework page.
Today, in the Java project, these two are only separated in different folders. In the future we want to reuse the framework wherever we want, so it is important to keep it dettached from any business logic. To do so, in .Net platform, I think it would be interesting to have these two in separated projects inside my solution. Then, in the future would be easy to separate it and even compile it into a dll to use in another projects.
Is this the right approach? If so, how can I make it possible since I'm having two web apis applications? As far as I know about a .Net project configuration, I have only one startup project (the one that is deployed). I can set a multiple startup configuration on those guys but I could only get them to be started as separated apps: localhost:XXXX/myapp and localhost:YYYY/framework. I need the framework to go "inside" the application: localhost:XXX/myapp/framework/framework-endpoint.
Thanks!
Found one solution that suits me by using AddApplicationPart().
Basically, on the Startup.cs of my BusinessLayerProject I configure the services as:
using Framework.Controllers;
// ....
services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2)
.AddApplicationPart(typeof(FrameworkController1).Assembly)
.AddApplicationPart(typeof(FrameworkController2).Assembly)
// ...
.AddControllersAsServices();
With this, if my framework controller has a route like framework/controller1 I can access it when I deploy the BusinessLayerProject
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
Broad, general question:
We have an app that is quickly approaching legacy status. It has three clients: Windows app, browser (web site) and mobile. The data access layer is convoluted at best and has grown organically over the years.
We want to re-architect the whole thing. The Windows app will go away ('cause who does that any more?) We will only have the browser based website and the mobile app, both of which will consume the (as of today, non-existant) API layer. This API layer will also be partially exposed to third parties should they wish to do their own integrations.
Here's my question:
What does this API layer look like? And by that, I mean... let's start in the Visual Studio solution. Is the API a separate website? So on IIS, will there be two sites... one for the public facing website and another for the API layer?
Or, should the API be a .dll within the main website, and have the endpoint URL's be part of the single website in IIS?
Eventually, we will want to update and publish one w/o impacting the other. I'm just unsure, on a very high level, how to structure the entire thing.
(If it matters: Each client has their own install, either locally on their network, or cloud hosted. All db's are single tenant.)
I would think one single solution with multiple projects.
If you put the API as a different site, you can easily add something like Swagger and Swashbuckle to your API
https://github.com/domaindrivendev/Swashbuckle
This will make documentation easy.
From here you would want to put your business logic (the things that do specific things) in a third project.
From here you have two options. The webpage can consume your own API, or you can reference your business logic project.
API on a different site offers some additional benefit if it is public facing:
Separation of domain
Load balancing and added protection
Resource limiting and throttling without site impact
These kinds of projects are a lot of fun, so consider your options and what will fit best.
I hope this helps!
my preferd way of doing this is with an seperate API project. you publisch the API project to one url and the website to another. this lets you develop both applications with no interferance.
that said, I normaly put the logic of the API in a Service layer (SOA architecture). My api project just pass the input to the sercice layer and response with the service response. this way you can seperate the api between public and private and still contain all the logic in one place.
usally i create a Api wrapper as a seperate project to handle all API calls, so other devs can use the API wrapper (just to make talking to the api more easy for my feelow devs)
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have the following code files in my solution:
The configuration is stored in a json file.
The shape of the data (model) is defined as a sealed class.
The configuration has to be read and parsed from the json file and stored into a public static class, so that it is available for use at run time.
A few helper libraries needing access to configuration data.
A few console programs making use of these libraries.
How should I organize the code into individual projects. Currently the console programs and rest of the files combined are stored as separate projects. Specifically, should the model of the configuration data and public static class holding runtime configuration, and parsing of json be an independent DLL?
There are very few reasons to separate code into multiple dll's, and odds are good you don't meet any of these reasons. Separation of concerns refers specifically to logical separation, and in the .Net world this is achieved via classes and namespaces. You can use the folders in your project to automatically assign the namespaces of the classes in them.
You are better off having only 1 project per executable and 1 project for all your business logic.
Here are a few reasons why you'd want to create multiple dlls':
Redistribution and copyright issues: You wouldn't want your customers to own server code. Create separate dll for client and server code.
Performance: if your dll starts bordering the dozens of megs, you may get some performance gains by splitting it up. (as with all performance concerns, you must first test and analyze performance bottlenecks before you implement any performance code).
Versioning and deployment: If you have a very large code base, and you know some of the code is more likely to change than other, you can split dll's in order to not have to deploy more "sluggish" dll's every time.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm working on migrating from ASP.NET 4/Webforms to ASP.NET Core/MVC. I'm new to MVC, but understand the concept. I have, however, ran into one issue with getting the handle on ASP.NET Core. I have several questions.
With my legacy (ASPNET4) projects, I wrote a "helper" library that provides basic functions for my web projects:
- Database Handling (connection, cleanup, error catching, caching, paging, binding, etc)
Misc functions (viewstate compression, date/time functions, etc)
Storage management (Sessions, cookies, etc)
Plugins (twitter, facebook, google integrations)
Identity Management (custom identity that works with other systems)
I think you get the point...
Over the years, I have developed this framework while constantly updating and bug fixing. It has become very fast and stable - it even handles any database you want to throw at it!
While researching, I found that .NET Core makes it hard for me to accomplish the same tasks. First off, it seems like CORE only supports object relational mappers (entity, dapper, etc). I'm perfectly content with ADO.NET, and understand the differences. I just really don't want to use the Entity Framework, or Dapper. I can migrate most of my code from .NET Framework. But it looks like ADO.NET isn't fully supported in .NET Core. Is this the case?
My next issue comes along after database support. I'm finding it incredibility difficult to manage things like sessions/cookies/etc from a class library. Perhaps I am misunderstanding the concepts, or not finding the proper documentation, but it appears as if it is nearly impossible to manage Session/Cache/etc in an external library. Is this the case? Or do I need to research creating custom middleware?
Basically, I need full access to the website from a library so I can use my own code to handle things like Sessions, data management, etc.
Is MVC the only option available for ASP.NET?
Finally, it seems like Visual Studio 2015 is very glitchy and slow with handling .NET Core applications. This has been a major turn off for me, everything from the interface to NuGet seems slow and glitchy.
Any recommendations or suggestions on where I should go or start with .NET core is greatly appreciated, I've spent weeks reading documentation and experimenting but have made no real progress. I really want to move away from webforms!
Next Tuesday (3/7/17) Visual Studio 2017 will release, which has fully integrated support for .NET Core. VS15 has the preview tooling right now, which causes a lot of the glitches you are experiencing. You might also want to consider converting over to the VS17 RC right now if you are early on in the process, as .NET Core 1.1 is much more friendly than 1.0.1 (in my opinion, since there is no project.json).
As for the database interactions, the idea behind Entity Framework is that it is a drastic improvement over having a DAL or another database service layer on top of your program. Through EF Core's Middleware/DbContext all database interactions can be completed with raw SQL or LINQ (or both). With this interaction, there isn't really a need to have the DAL/ADO layer.
Entity Framework is built on ADO.NET, and is a drastic improvement over other entity relationship libraries. See mason's comment below on ADO.NET on wikipedia for a better look at this.
As for the cookies/sessions, I'm not terribly experienced with this kind of information, but the one thing you might want to look into is the ASP.NET Identity for user information and sessions. IdentityServer 4 is another option.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
We have web application in asp.net mvc using razor code. Now along with web app we need android app. So whatever operations done in mvc controller need to shift in web API controller. So is there any way to convert mvc controller to web API controller? and is it a good approach to call web API in mvc controller?
This is a very common scenario these days.
To answer your question, no you cannot simply convert an MVC controller to WebApi. For one the API is stateless so you need to take that into consideration.
My suggestion is to create a separate WebApi2 project and create the controllers you need there. There may not even be a 1 to 1 correlation to your MVC controllers.
Think of this web api project as your data layer, in a way. It will simply provide the data you need, maybe create some new things and that's it. If you need to save / load data from a database then that's where you do it so both the UI and mobile app use the same data store basically.
Start small, create one controller first with one method in it and then have your MVC app call it and use the data. When you deploy somewhere you will deploy two things :
The UI app
The WebApi project
This means you will need to keep the URL of the WebApi project somewhere so your UI knows about it.
Once you achieve this separation move to your mobile app and call the same WebApi method you've just implemented for the UI project. This will be your Proof of Concept basically.
An Api comes with its own set of rules and challenges, for example :
which methodology are you going to use? REST or not.
How are you going to secure it?
I suggest looking into OAuth2 with JWT for security and if you are interested I can provide some links.
Here is the blog of Taiseer Joudeh, who does a lot of stuff on OAuth2, you'll find loads of articles on the subject there : http://bitoftech.net/taiseer-joudeh-blog/
Here is an article I wrote on OAuth2 and JWT which will take you through a lot of different things :
https://eidand.com/2015/03/28/authorization-system-with-owin-web-api-json-web-tokens/
I always see a controller as a hatch. My controllers never has any business logic. Any logic comes to seperate libraries, which can easily include an API.
be sure the make use of the await keywords for async methods when using API's.
So just replacing your controller logic to an api should work, If you not using many function from the base class which you inherit from webcontroller.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
The company where I am currently employed is struggling with an architectural decision for our range of applications. At the moment we have a couple applications that have common parts (think like a calendar module). Until now we kept on copying code from other existing application, but in the future we want to evolve our applications to a more modular design:
As you can see in the picture above it is possible to have different versions of modules per application.
We are considering to possible solutions:
Building a core application framework where we can install our
modules in. We're think about a tool like Nuget to accomplish this.
Building one application where all our modules are included in (=one code base), but the customer only gets the functionality that is activated for him. We're forseeing some problems with versioning here.
Any suggestions on this? We can't be the first company who struggles with this problem?All our applications are ASP.NET MVC 4/5 web applications, built with Razor Templates or JavaScript templates (knockout.js). All of our applications are deployed on Microsoft Azure and we have extensive inhouse knowledge of buildscripts (MSBuild), CI Servers...
Having separate project/assembly for each module and delivering it as Nuget package is definitely a good strategy.
Advantage:
Can maintain and release multiple version. Different client get different version.
Installation of latest or specific version supported through Nuget. This helps during development where App A developer can target 2.0 version of module A while App B developer can target 1.0.
Single source base with separate branches for each version. Client using 1.0 request a change will get code from branch 1.0 with just the fix requested.
Each module can be released or updated independently.
Challenges:
During development debugging assembly code that's installed using Nuget. Nuget supports it inbuilt. We achieved it in our case (Framework being used by multiple platform).
Code changes required in module code (a bug or a new feature required). Well this is tricky:
Option 1: Same developer just go ahead and make that change, create new package and install new version in his app. Got to authorize the change as it is critical code.
Option 2: A designated team responsible to fix issue or change request in framework code.
You can also try using the plugin architecture, just build the different modules that makes up the application as a plugin, then build the module that is required for every application as a single code base. In this case, installing a component for any particular user, will be a matter of adding or pulling out plugins. Many large projects makes you of this particular architecture as it reduces copy and paste, increases and reuse and speed of development. You can check nopcommerce an open source project for an idea of how it is done.