I have built two projects in my VS solution. One is a MVC web applicaition and other one is a standard C# windows form project. I want to transfer data both ways. For exmaple the input from my MVC web application to the form and then output back to my web application from the C# form project. However, I can only do refrenceing from one side and access the static variblias of only one project from another. To achieve my goal, I need to do circular referencing which VS is not allowing me. Is there a workaround to my solution.
PS: My main goal is to access all the static members of every class into every other class in my whole solution.
Separate the static functions in a separate library and then reference that from windows or web application. That way you will also know what are common functions and what functions are specific to those feature or class.
It is not a good design to let "access all the static members of every class into every other class". It violate OOPS principles.
If its shared data save it to any repository and access it from there from both of your application.
Related
I am at the point in azure manager where I have to choose for xamarin.forms: create new app(too much unnecessary content) or connect an existing app(which I think is better). I have a blank xamarin.forms project and I cannot figure out in which specific files to put necessary items, basically I would like to know the file names and place to put each item in according to this(starting from "In your main Activity file...").For example, which is the main Activity file?
If you want to create Xamarin.form app with Azure, you can take a look the following article:
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-xamarin-forms-get-started
And you could be confused about xamarin.form folder, when you click corss-platform---Mobile App---OK, your solution will be created with four projects, you will have three platform-specific projects and one Shared Project. The Shared Project contains the application logic as well as all the Xamarin.Forms code that will be in charge of creating the screens (Page objects) of your application. More detailed info, you can take a look the following article---Creating basic Application.
https://code.tutsplus.com/tutorials/getting-started-with-xamarinforms-basics--cms-21564
I have a WebAPI running on Azure WebApps developed with EF Code First.
Now I need WebJobs for some scheduling tasks which should refer to the same DB and Models.
I tried adding reference of the WebAPI project but that marks the DLL as yellow exclamation.
I'm unable to get how should I proceed. Can you please guide me a bit?
As Frederico suggests, you should split your Web API project into multiple projects.
If you isolate the Data Access Layer (EF Context + query) into a separated assembly, it will be easier for you to share the database access into several projects. Moreover you will not have to add reference to web specific dll (for example System.Web.Mvc or System.Web.Razor) into your webjob project.
Anyway you have some yellow warning because your Web API and you Azure web job don't target the same .Net framework.
Right-click on your project then select properties. you should be able to adjust the .Net Target framework.
To be able to reference a project A into project B, the project A should target a .Net framework with a version less or equals than the targeting .Net framework of the project B
I assume that your EF DbContext class and entities resides inside your Web API project. This monolithic approach brings many problems in integration scenarios like the one you shown.
My advice is to modularize your solution and move all your Data Access related classes (DbContext, entities) inside another project which will be referenced by both your Web API and WebJobs projects.
This is a common approach for improving the maintainability of the code and enforce basic software engineering principles like separation of concerns, and is obtained by dividing your application into different functional layers (a.k.a. multi-layered architecture).
If you are interested you can read more about it here: https://msdn.microsoft.com/en-us/library/ee658109.aspx?f=255&MSPPError=-2147217396
I upgraded from VS2005 to VS2012 specifically to code in .Net 4,.Net 4.5, and use EF5. I am new to EF. I have Julie's EF book but it talks mainly about EF4 and POCO and it has me confused trying to implement EF5.
My hosting only allows me to run .Net 4 currently. I am trying to use EF5 on a new database.
I tried Code first to generate my database but I could not get it to generate the database. So I created the database first and then generated the model from the database with EF5. What I want is a layered website using ASP.NET Forms, Data Access Layer, and a Business Layer. The business layer I intend to build so I can use ObjectDataSource to pull in to the webpage along with some web services to use cascading dropdowns.
I have my NameX.edm model created but the tt files don't have the same names, they have Model1.tt and Model1.Context.tt is not the same name, why. Also Model1.Context.tt is empty. I am attempting to create the POCO classes running the EF5 DbContext but I am having trouble getting it to see the edm model. I read somewhere that EF5 creates the POCO automatically. I am not seeing the big picture here. Is my issue that I am not using .Net4.5?
What I have is a ASP.NET Application project, a EF Project, a POCO Project, and intend to have a forth project with the Business logic. How do I get the EF generated correctly and the POCO classes? I want a layered application for to scale well. Next question How to get the POCO classes to talk with the Business logic? My database is SQL. I am use to writing stored proceedures to accomplish everything through business logic.
If you are using Model First technique, make sure that you have references to System.Data.Entity and System.Data.Entity.Design. Also, you will need to create a reference to the EntityFramework.dll as well. It is located by default in c:\Program Files\Microsoft ADO.NET Entity Framework Feature CTP5\Binaries\EntityFramework.dll. If you can not find it, make sure you have installed the Entity Framework through your Package Manager Console. To do this, open up Tools, Library Package Manager, Package Manager Console, then type Install-Package EntityFrameWork.
Next you want to add a new item to your project. Right click on your solution, go to Add, then select New Item. You want to select Data from the Common Items section on the left, then select ADO.NET Entity Data Model.
Next Select Generate From Database. In the next screen, if you have not set up your connection to the server, click New Connection..., otherwise select your database from the drop down box. You need to select whether or not you want to include your connection string information in your config file. This is up to you how secure you need your application to be. If you choose not to, you need to pass this information as parameters in code. Also at the bottom, you will most likely want to change the auto-generated entities name to something easier for you to use. This name will be the name of your DBContext Class!
Next you want to select the tables you would like EF to create POCO's for. If you want all the tables just tick the tables items. Same goes for views and stored procs.
Once you click finish, then you should see all your fancy POCOS laid out in front of you in Design Mode. Note If you do not have primary keys in place for all your tables, I suggest you fix that! VS will spit at you if you do not have Primary Keys set, or if your naming conventions in your tables prevent VS from creating them for you implicitly.
This is a quick little tutorial on getting you up and running. You can now persist and pull data from your POCOS by using your DBContext object. For example if you named your DBContext class *Gary_Bettman_Sucks*, and you wanted to create a new record from your table called NHL you would do the following:
Dim context as New Gary_Bettman_Sucks
Dim PullMyGoalie as New NHL With {
.Goals = 0,
.Playoffs = False
}
context.Set(Of NHL).Add(PullMyGoalie)
context.SaveChanges()
I would Highly suggest you look into implementing the Repository Pattern with your design to encourage code re-use, and it will seriously make your life MUCH easier down the road.
Hope this helps!
Which design approach can be used, already exists or new ones to implement security system in MVC web-application?
Possibly there are patterns, best practices, e.g. in some popular languages, e.g. Java, .Net or whatsoever?
On which level is it better to implement it: model or controller or something between them?
I faced that primitive approach results in spreading security checks among many controllers or models depending on implementation, mixing with code of levels.
But it is not obvious for me in which way to design security in better way.
I have an MVC application.
I need flexible system of access rights.
I have and hierarchy of categories and entities in categories.
Some user can edit/view/add/remove one on set of categories, another users - other categories.
It is also required that depending on user role some fields of model should not be retrieved from DB (null should be returned)
Admins should be able to assign different access rights.
You should be using .Net's built in member ship providers. By default a new MVC 3 Internet Application Visual Studio project template will give you basic login code. Clicking on the 'manage' your site button from within visual studio will give you the web interface to manage the users and roles. Create your users/roles, then define [Authorize(Roles="Admin,Users")] on your Controller class definition or on your method definitions. DO NOT define URL access as was done in Asp.Net Web Form applications as there are multiple URLs that could map to a single place. Use the Authorize attribute instead.
Also check my response here:
What features do I need to have before I open an ASP.Net app onto the internet?
In addition make sure you use Html.AntoForgeryToken in your views and [ValidateAntiForgeryToken] on your [HttpPost] controller methods (ie any methods you post back to)
I understand the pros of using namespaces within the actual application layers but when it comes to the front tier, I am not so sure.
My project is a Website (not WebApplication) and I get all sorts of problems (missing references, for one) when I try and include "namespaced" user controls. Despite explicit declarations in web.config under system.web - pages - controls - add.
When it comes to the actual views, the webforms: when you create a new page, Visual Studio creates the codebehind classname from the path where you chose to create the file. So most times, I'd say that class names will be unique. If you move around pages, then it will become strange to see say Start_DefaultPage but under another sub folder.
To summarize: Is it recommended to put namespaces into the web tier? What are the pros and cons?
Yes. In the future, you may decide to include external libraries that (coincidentally) use the same class names, and you do not want to have a namespace collision, as you very well know can occur. In addition, you may have web applications in a virtual directory that will inherit the properties outlined in the parent web.config. You do not want to mess with namespace conflicts there, either. Generally speaking, it is just a good programming practice.
Your problem is that you are using a web site "project". Stop doing that, and you'll stop having these problems.
Web Sites are a mistake that Microsoft made. There's no need for you to make their mistake into your mistake.