Where to put my Classes/Objects - General Project Design - class

Lately I seem to be struggling to organize all of the different Classes/Objects I am working with. In my case, I work for a company that has 3 core products that are different - but share some core functionality. So, they will also share classes. To muddy the waters some more, I am writing ASP.NET MVC app - which has an implicit location for Classes (the Model folder).
So - here is how we are currently doing things. I am going to refer to the product as NewProduct. xxx is the company name:
xxx.Core - Classes used in all products. These could be helper functions, actual classes with logic, etc.
xxx.NewProduct.Web - The MVC Web App for the NewProduct. The Models folder is empty.
xxx.NewProduct.WindowsService - A Windows service - part of the NewProduct.
xxx.NewProduct.Models - Basically, this replaces the Models folder in the MVC Web app. They are in their own project so that the DomainLogic can fill them and pass them back to the MVC App.
xxx.NewProduct.Objects - Classes with logic (not just Skeletons like Models) that are shared between Web and WindowsService.
xxx.NewProduct.DataAccess - This is the DAL, not all that important to my question here.
xxx.NewProduct.DomainLogic - This is the business logic layer (makes calls into DAL).
Also, if we are to write some other app in the future (Mobile, Desktop, etc) these can be reused by it as well.
My main problem is when I am trying to decide where to put an object, there are times where I am not sure where to put it. Is this normal? Do others have this problem? Any suggestions?

of course it's normal! there is no one right way to divide your modules. but don't spend too much time on this. we are living in IDEs age - you can always refactor. for me, the most important is readability. when other programmers from your team look for the some class/functionality they should not be surprised - that's all. for example i have no idea what can i find in module named Objects (but i don't know .net nor specific of your application).

Related

Can’t find best way for apply best in code design techniques in software dev

[Pre]
I have to say that I'm dummy newbie who is trying to get together important puzzles with such crucial details as DDD, TDD, MVVM, and EFCore. I have an about 10 years of windows form develop experience in complete wrong manner, and after I'm joined to Plurasight I'm understood that I'm just lost my last 10 years, and this is really sad :).
[Problem description]
I have an App that i want to re-write from scratch by using latest and greatest technics that've learned for the last 6 month on Pluralsight, but the problem is that these new knowledge’s is stopping me, because simply I'm afraid that I'll do it wrong again...(that is stupid I know, but it is what it is).
So back to my questions, I have a big problem domain, and pretty well documented business logic, which i have to turn in to the code. I'm understand that my start point is design data layer, for these purposes I want to use Entity framework core (I saw Julie Lerman's course on Pluralsight and I think's she is amazing and inspires me to use EFCore as ORM for my app). But at the same time leakage of experience produces more questions than what I’ve learned with Pluralsight, and I will try to write them all(please don’t judge me too hard)
It is looks like that I will need 2 or even more data model projects in my solution, and here is why I have multiple document set types, each of the type contain more than one reference books used to generate unique file names and data sheets. But it looks weird to me have 3 Data model projects such as MyApp.PackType1.DataModel, MyApp.PackType2.DataModel, and each of them will be preinstalled with the EFCore, and each of them will generates its own database based on Data Context defined by EF. Isn’t it very redundant or this is correct way?
I don’t understand how to join these multiple Data Models projects, including Shared Kernel into the one nice model
I don’t understand what is the best way to design my data classes? Should they be just POCO’s or I can design them as nice looking classes with the private var’s and public properties? What are the best practices in here?
Also I don’t understand what is the best practice to use a MVVM pattern on top of that, and is it applicable at all to use MVVM in this case?
Should I keep my Tests in separate projects like MyApp.PackType1.DataModel.Tests, or keep them in same project?
Best regards,
Maks!
P.S.
Apologize for unclear definitions and questions, English isn't my native language.
It's very complicated to answer your question because you have asked for a lot of details, but I going to provide a brief answer and I hope it will be helpful.
You can have only one model for your entities (DDD) and create sub model from this model in your end level projects (Web API or UI)
Read point #1
You have to create an Entity Layer project that represents your database and then you can create DTO's for specific scenarios
From my point of view, use Angular but you can use another UI framework such as React or VueJs, but I prefer to use Angular to build UI interfaces and consume .NET Core Web API from client
Create unit tests and integration tests for you Web API projects and as additional feature you can use Db in memory provider for tests
May be this guide is useful: https://www.codeproject.com/Articles/1160586/Entity-Framework-Core-for-Enterprise
Regards
Hm, multiple DbContexts (models) usually come about when you have distinct databases you are using. General rule is one Context = one Database. Exceptions can occur when there are a lot of tables that can be grouped functionally, but there are downsides to that approach.
A DbContext is a repository pattern but for individual tables. Using a Unit of Work pattern and layering with a custom repository provider would allow you to make it "appear" as a single database, hiding the complexity from the front-end.
Your entity descriptions are usually created as straight POCO. You can get creative with different DTOs
In a nutshell, an MVVM pattern goes like this:
Request from UI to a controller
Controller possibly issues multiple calls to Data Layer to gather data
Assemble data in a single ViewModel (everything the page needs)
Return to UI
The beauty of the approach is single roundtrip (request/response) to the UI
Separate Project in my opinion. There are techniques to spoof the database connection using EF so you are not using "live" data.
That CodeProject article will come in handy.

Why is there no suggested "model" folder in a Durandal app?

I'm working on a Durandal SPA, and I've setup some views and viewmodels. However, I thought the MVVM architecture would also involve a "model" segment (Model, View, ViewModel--right?).
However, the Durandal Getting Started page says this under the "Organization" section:
If you expand the App folder, you will find the source for the entire
SPA sample. Here's the high level organization you will find:
App
durandal/
viewmodels/
views/
main.js
Absent from this structure is a "models" folder. Where are you supposed to put your models in a Durandal app?
I've looked at some other sample apps, and I can't find a "models" folder (or anywhere that models are residing) for any of the sample apps I've reviewed.
The "models" folder (which isn't there) seems to me to be a critical part of a Durandal app. However, it's not there--and therefore, I am questioning my understanding of how Durandal (and MVVM apps) are designed. There is surely something I am not understanding... can someone fill me in on the intended structure of a Durandal app, and where to put your model objects?
The answer is that Durandal only gives you the structure necessary to run, and nothing more. It uses a viewmodels and views folder, so it tells you to make one. Durandal doesn't use a models folder, you do.
I make one in my projects. If you feel like it fits your dev style, you can and should make one yourself.
Notice that it also leaves no place for code that is not a viewmodel, which surely will exists in any application. I highly recommend making a modules folder for this purpose.
Don't think that the only things you can or should do are the ones you see done in the Durandal tutorials. You are the developer. You will have to build on top of what Durandal provides, and this means making your own choices.
In my applications, the models have always been defined by the REST services or WebAPIs that the app makes requests against. I haven't had a need to define those models in the application code. The models are defined by the server/service side.
When using something like Breeze, the model is just a JSON representation of your entity models in your database.
If you feel more comfortable defining those models in your application code, you are more than welcome to. If I did something like that, I would put it in a App\models folder as you suggested. I don't think you will need to do this most of the time, though.

Good class name for persistent class?

I have several classes that exist persistently throughout application lifetime and can contain any code a programmer might need to run (stuff like for example that is executed when a user resizes the app window). These classes are basically empty templates and aren't for a single task (uh oh, sounds like bad OOP, but please stay with me here). There are several of these classes in my framework and which one is integrated into the rest of the framework depends on the build target (web, desktop, mobile, etc). Currently these classes are named:
AppModule
AppDesktopModule
AppAndroidModule
etc.
But I'm not happy with this naming. I'd like to give them a name that somehow clarifies that these classes are persistent throughout app lifetime. Does anyone have ideas for a better naming?

ASP.Net MVC real world-level sample business applications

I need to re-write a businesss InfoPath / SharePoint application that has a fair bit of logic associated the operations a user performs - such as enable / disable controls; show / hide controls (complex tab controls); retrieve different data nad display differenty - as determined by user activity.
In trying to decide whether to use ASP.Net Web forms or ASP.Net MVC. As such I have been hunting around for a good realworld ASP.Net MVC sample business application (with Source code).
Does anyone know of anything that can demonstrate to me how to achieve the 'richness' of user interactions and responses in ASP.Net MVC that one can achieve using Web Forms?
I am know the Dinner Nerd application; and have checked out the offerings on CodePlex. So far most of the sample applications I have found do not have much of the complexity we have become used to dealing with in Web forms; and that I need to try and achieve. I posiibly have have to rethink the presentation & flow of the application in response to user actions in an MVC application (as compared to how one migh structure the flow in InfoPath / Winforms and Web forms). This might shift me more to what the existing sample applications might be indicating to me -'change the focus of the Views to be of presentational bias'. As such one would end up with many views each only permitting a reduced set of use interactions.
Thanks for any comments in advance.
Grant
There is exactly the same question asked here (ok, it is not about business apps) - Real World ASP.NET MVC Applications with Source Code?
just keep in mind that asp.net-mvc makes it really easy to write unit tests, which is the most important thing when coding applications.
If you have complex interaction scenarios you might be interested in performance too, asp-net.mvc performance is a way better...
Asp.net-mvc 2 (I haven't looked at 3 yet) makes the validation really easy and you can choose at which level you want it.

ASP.Net MVC 2 File Organization; Views and Controllers

I am part of a development team implementing a large application. There are several layers to the application, and we'd like to make the organization of files as easy to maintain as possible, but also follow best practice.
Here is an example of how this is laid out based on MVC convention.
UIProject
- Controllers
- HomeController.cs
- ErrorController.cs
- PersonalInfoController.cs
- BaseController.cs
...
- Views
- Home
- Index.aspx
- Home1.aspx
- Home2.aspx
- PersonalInfo
- Step1.aspx
- Step2.aspx
- Step3.aspx
...
- Shared
Site.Master
Error.aspx
...
However, we have realized that the functionality of PersonalInfo has grown, and really should be broken down into multiple controllers. We'd like to organize them in a subfolder of the Controllers folder. Something like this:
Controllers
- HomeController.cs
- ErrorController.cs
- BaseController.cs
- PersonalInfo
- Step1Controller.cs
- Step2Controller.cs
- Step3Controller.cs
This can be done, each of these controllers would be within a PersonalInfo namespace. A Route can be mapped using the namespace argument.
The real issue comes in with getting MVC to find the associated view. I have found two ways to get around this. One, by clanmonroe.com, handles this by inheriting from a base controller that specifies a hardcoded viewpath. Another, by Stephen Walther, more simply suggests providing the view path in the call to the view.
Both of these methods seem to work, and I'm more partial to the first method. However, they have drawbacks. Mainly, that we now no longer force the convention. That is, Step1Controller.cs could have an Index Action, but the View could be named foo.aspx.
Ideally, we'd like a way to implement an organized approach using MVC natively, w/o quirky workarounds. Is there an established best practice for situations like this, or at least a good recommendation?
This sounds (more or less) like the new areas feature in ASP.NET MVC. According to ScottGu:
Areas provide a means of grouping controllers and views to allow building subsections of a large application in relative isolation to other sections. Each area can be implemented as a separate ASP.NET MVC project which can then be referenced by the main application. This helps manage the complexity when building a large application and facilitates multiple teams working together on a single application together.
It's not implemented exactly as you describe it, and rather than a sub folder within Controllers, it expects you to split your areas into seperate projects. Each area can then contain both controllers and views.