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
Given a huge EF MVC solution where there are separate projects for data models, services (interfaces and their implementations) and repositories. It is necessary to create new files with given structures, e.g.: different using, namespaces, etc.
Example
New database table is created with the following names:
SomesSession
SomeQuestions
SomeAnswers
SomeScores
Four files under the Models project, four files under Services - Interfaces, four files Services (where implementing the interfaces), four files under Repositories.
Is there or what is the best way to make automatic this tedious task?
Maybe Visual studio macros?
Out-of-the-box Visual Studio templating to generate code on Entity Framework and many other frameworks is implemented using T4.
Check this MSDN article to learn more about how to implement these code generation templates from scratch:
Code Generation and T4 Text Templates
Related
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 2 years ago.
Improve this question
I have a relatively comprehensive solution that contains about 20 projects. One of the projects is "Utils", which I would like to have shared for other solutions. Unfortunately, if I added this project to another solution as a linked project, then this project didn't upload me to Git for this solution, so then teamwork is not possible. Therefore, I am looking for a solution to achieve that I can share the source codes of this project between the individual solutions. I use VS2019 and as a Git repository xxx.visualstudio.com. Thanks for the advice.
If doing a nuget package is not a solution for you because it add too much friction (even if you could also give access to the util repository), and that you want to be able to update the "Utils" source directly from the sln file, then the solution for you is to use Git submodules.
From the documentation:
It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.
You will have to create a repository for the "Utils" code and include it in the other(s) repositories as submodules.
But Visual Studio still no support it...
It's not crippling because you could still use it from the command line or from an external git GUI that support it (like GitExtensions for example).
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 just found about the ASP.NET boilerplate framework for ASP.NET Core applications. The boilerplate is cool, it has all the necessary structure we need in order to create a SOLID proof web application.
My question is that, as per the site I have to create entity models in .Core project, and Dto's in Application project but as I can see these Question, and Answers are different entities but they kept both of them in the same folder and same namespace.
It does not look like a good practice, can anyone tell me is it wrong to keep these related entities in the same namespace/folder or it's ok to do so?
You can locate entities/services into any namespace. This is not related to the framework actually.
Question/Answer application is very simple project where there are just 2 entities. I thought that Question is aggregate root and answer is a child entity (they are a single aggregate together). This is why I put them into same namespace.
I suggest to follow "namespace per aggregate" principle, but "namespace per entity" is also fine.
BTW, #Dongdone, AspNet Boilerplate is completely open source & free. We have a another product, AspNet Zero (https://aspnetzero.com) that is commerical and developed on top of the ABP framework. But that does not make the ABP framework a paid tool. It's absolutely open source & free.
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 5 years ago.
The community reviewed whether to reopen this question 7 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am developing an N-tier application and want to create each tier separately (i mean not in one solution), so i have the DAL, BLL and Entities DLLs created separately, then i reference them in my presentation layer solution, anyway, for quick maintenance, i thought on creating a solution in which i add the projects DAL, BLL, Entities and the Presentation layer as existing projects, is it ok or it will have concequences ?
Every decision has consequences.
Splitting an application into multiple solutions has some positive and some negative. If you have dozens of projects, multiple solutions is a good way to reduce load and navigation time. However you may spend more time flipping between solutions or instances of Visual Studio.
You can also put the same projects in multiple solutions; solutions do not have to represent a physical folder necessarily. If you "add existing project" you can grab an existing project from another solution and have it in both solutions.
Generally, I avoid this because it can create issues with multiple instances of Visual Studio using the same files, but it can be helpful at times. Usually I only do it for debugging help when working on the boundaries between two related applications in different solutions, or an application and a library it consumes.
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 7 years ago.
Improve this question
I have a Visual Studio solution which contains several projects :
Domain classes
Data access layer - which contains DB context
MVC application.
The MVC application by default uses existing classes for user management and it also has his own ApplicationDbContext. In this case we have two DB contexts.
What is your experience regarding the user management ? Would it be better if I create my own classes for user management and place them to the Domain Classes project. I think it would be much easier latter for maintaining and in this case there will be only one DBContext. Another possible problem can be relations between existing ApplicationUsers(from the MVC project model) and classes from the Domain Classes Project. Or maybe to move the ApplicationUser class definition to the DomainClasses project ?
I highly recommend MembershipReboot. You have the option of using its built in UserAccount or using your own.
On a side note Brock is part of Thinktecture. In one of the asp.net stand-ups it was mentioned that the team may just recommend a 3rd-party identity provider instead of role their own. That was my understanding but maybe I am just being hopeful. I think it was this one https://www.youtube.com/watch?v=CMTd5yS-yFE&list=PL0M0zPgJ3HSftTAAHttA3JQU4vOjXFquF&index=2 but don't hold me to that.
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 9 years ago.
Improve this question
I am starting a project in asp.net. I want to use 3 layer architecture. now I have problem with layers. I manage these layers like this:
but I have seen somewhere that uses App_Code and some other formats. could you please help me which one is true and standard?
App_Code is a special ASP.NET folder which is used by ASP.NET Websites. It is not used by precompiled ASP.NET applications. You can read more about the differences between the two in this article. So if UI is an ASP.NET Website you could use the App_Code folder to put some logic although this is better suited to external libraries as you have in your current design. This allows for better unit testability of this code and reusability.
Avoid the use of App_Code. Anything you put in here doesn't compile until the site is executed. Any dependency that your forms and user controls have is best put into your UI layer, outside of the main web folder. You'll have a lot more peace with objects that are compiled early rather than later.
Now-a-days I see this standard a lot:
ProjectName
-ProjectName.Core (All poco classes and interfaces)
-ProjectName.Data (All entity framework stuff)
-ProjectName.Service (All business logic)
-ProjectName.Web (All font end logic)
"Core" is reference in all projects to move data around.
"Data" is referenced only in "Service".
"Service" is referenced only in "Web".