One logic implementation for Web and Console Application? - c#

I am new in C# console application.
I have a question: I want to create a MVC project using Entity Framework, I have made some logic to import data one table to another.
Now as per client requirement I need to create a console application for same logic.
Now my question is : how can I use my mvc application logic in my console application?
So if I need to do any changes in my code, I have to change only in web applicaion not in console app.
Please suggest a good way to make efficient my logic
Thanks

You'll end up with 3 projects;
The Web Application
The Console Application
A Shared Library
What you would do is,
Refactor the shared logic so it exists in separate methods and doesn't depend on any shared state specific to the web application.
Test the web application still works.
Take out the shared logic and put that in the shared library.
Add a reference to the shared library from your web application.
Change the web application to call the functions in your shared library from the web application.
Test to ensure it still works.
Create your console application.
Add a reference to your shared library from the console application.
Call your functions in the shared library as needed from the console application.
Test to ensure it works
Yay, you're done! \o/

To elaborate a bit on George's answer, you need to implement SOC (separation of concerns) in your app. MVC is a framework that helps you do that, there is also MVP which could be even a better solution in your case.

Related

Web API project structure and architecture

Solution Structure:
MyProject - WEBAPI
MyProject.CORE - Class Library
MyProject.Models - Class Library
MyProject.DAL - Class Library
Project References:
MyProject refers to CORE , MODELS
MyProject.CORE refers to DAL,MODELS
MyProject.DAL refers to MODELS
Project Description:
I am trying to create an application with ASP.NET MVC WEB API . so that I can call my API in future mobile applications. My idea behind this layered architecture is WEB API project will hold the front end views of my desktop application and call's the API controller methods on button click events . The event handler methods in API controller will call the Methods in the CORE project where I will implement the business logic.Then the call will be going to DAL where I will call the DB Stored Procs to insert data. As MODELS project is referred to the rest 3 , I will be able to transfer Objects across them.
Here are my questions below.
1) Can I use the same web API project above to create views of my desktop application and call the API controller methods on events like button click?
2) I don't want to expose the implementation of my business logic in CORE application to any other referencing projects. But still i need to follow a layered architecture.
How can i achieve that. Please explain with an example.
3) Is there any best architecture that i can follow with the above requirements.
4) Is this a valid architecture for WEB API and will this work?
Please take the Model example as UserModel {Name, Password, Email}
I assume you meant 'solution', not 'project'. Yes, you can keep mixed types of projects inside one solution, that is Web API for IIS hosting and WPF app that references your core.
This is where interfaces and dependency injection come into play. Create separate interface project to reference and use some dependency binding module like ninject or Microsoft Locator
When following any architecture pattern, remember that patterns were created for developers, not the other way round. What am trying to say, that when you follow any architecture, you - and only you - know what you are trying to achieve. Don't stick to any pattern if you don't know what are you doing and feel free to bend any pattern to your needs. For now keep it simple.
Yes.

Separate projects for MVC5 and Web API 2

I am new to MVC and Web API. I created two separate projects. One ASP.NET MVC 5 (MyUI) and other ASP.NET Web API 2 (MyApi). I would like to keep my API project separate from my UI layer.
The AccountController class in MVC project (MyUI) is essentially doing the same that the AccountController in the API project does (MyApi). I first thought about making the MyUI.AccountController a sub class of MyApi.AccountController but then I quickly realize that first inherits from Controller and second from ApiController type.
So my questions are:
In order to remove data access logic from MVC 5 project, should I
just convert the AccountController to a wrapper class which will
essentially call the corresponding methods from the
MyApi.AccountController?
Is there a better approach?
Edit:
Edit 2:
While trying to articulate the problem I realized that I was going about it incorrectly. My confusion came from the ASP.NET Identity implementations which were embedded within the API project. That needs to be moved to the Data Access layer and both controllers need to access them the same way which is a whole different can of worms :)
Thanks!!
Method 1 seems a plausible solution but what I would suggest is to create a new class library and there put your data logic. In that way, the MVC project and the Web Api project could connect to that class library.
The reason is that you never know if you write another UI layer, Service layer or other connectivity layer. All those layers could then connect to the same data logic layer.
Extract the common implementation into a separate project (a class library for instance). Your business logic must be the same no matter how you access it. After all, the web service and the site are only a view of the same information and the same control logic. In the future you might be required to write a fat client in WPF or a service in WCF and you do not want to rewrite everything, do you?
I think you are asking about layering application. basically the choice depends on requirements.If you are following data centric design check this layering
Research about DI,ORM,Repository Pattern, SOLID Principlese

web app to console app?

I'm working with this small web application (1 page) built by someone else that does a specific task after pressing a button on the web page.
Now the requirements have changed slightly, and we need to automate this to run weekly without the need of user interaction.
What would be the best way of doing this, minimizing the changes done to the code?
I was thinking on adding a console app to the project that then references internally the web app but that doesnt seem to work.
Or maybe converting the web app to a to console app, if that is actualy possible?
Is there any straightforward way of doing this?
Thanks
First, make sure the "specific task" is broken out from the Web application so it resides in its own .NET project. Even if this project just contains one class you're "separating concerns" between the Web-based UI and the task itself.
Then you can create another "wrapper project" to call this new project as you wish. A console application might well do the job -- you can run that using a Scheduled Task -- or you may prefer to use a Windows service.
It really depends on how well the existing code is structured. A common approach is to divide business logic from the presentation layer. In VS, it's normally done by creating a class library project and keeping all the business logic in there. A web application project would then just instantiate business logic classes and run their methods.
If it is done like that, you just need to reference the class library project. If, on the other hand, you have all the logic in the web application project, probably there's no fast way of doing that, as you're not supposed to instantiate Page classes manually (well, you can do that as well, but that is clumsy and not recommended).
So in that case, you should create a class library project and move there all the logic you need to use in your console app. I would imagine that would require quite a bit of refactoring.

Can anyone suggest some good links about ASP.net based n-tier architecture

In my Visual Studio solution I m having following types of project:
Class Library - BusinessLogicLayer
(I m in doubt how to seperate functionality in BLL)
Class Library - DataAccessLayer
(I m in doubt how to seperate functioanlity in DAL)
Class Library - DataModels
(Contains various models like User,TimeTable,Address, etc.)
WCF Service App - To create common WCF service which can be consumed from jQuery(Web App) and WPF App
ASP.net WebForms Project - Web Pages
WPF Project - Windows application for same (As it is the requirement)
Setup project - Septup project to create installer for Windows app
UnitTest project - Project to make NUnit basd test cases
Can u please tell me whether or not I m going right way?
This is my first n-tier based application.
I m actually not clear to seperate functionality in layers even in my very first screen that is login screen.
It could be like this way from code behind file login.aspx.cs in OnClick_submit event I should create instance of UserBLL class and then I should call obj.validate(username,password) which returns a model of UserInfo. While that BLL class should itself call UserDB.Validate(username,password) method which returns model back to PersonBLL class.
If I use this scenario then every operation needs a seperate db conenction.
I also want to asks whether or not creating applications in this layered approach results in any extra memory consumption.
Please explain the scenario to me if you are familiar with this.
I don't know about others but I find working code to be a far better way of getting a handle on best practices. Therefore , I'd strongly recommend downloading the Patterns and Practices Data Access drop on Codeplex. It's a little old now but will provide you with a comprehensive reference sample for a Web (albeit MVC), WPF and tiered Services application.

Can a console project reuses code from a MVC3 EF4 project (in same solution)?

I am currently programming a ASP.NET MVC3 application, using Entity Framework 4.
There are certain tasks (processing 10K+ of records, for instance) that has to run in the background. I am writing a console application to do the job (and maybe run it as a thread or window service).
Both the console app and MVC3 EF4 project
Since I have written lots of services and model code inside the MVC3 application, I would like to reuse that in my console project.
Is that possible?
(Due to time constraint, I cannot refactor our the services into another DLL/code library)
Moving the services and model code into another DLL shouldn't take more than about 10 minutes, if that. You don't even need to change the namespaces if you don't want to - just create the new project, move the files over, add a reference to the class library from both the console project and the MVC project, and you should be done.
It depends on how you have built the MVC system and which parts you are going to use in your console application.
Eg If you are going to reuse Controller logic in your console app you need to provide fake implementations of numerous classes. Eg HttpContextBase.
Further more if you have use Session, Cache, HttpContext you will have hard time using the code base for the console app.

Categories