I want to develop my wpf project by using MVVM pattern. Should I create new folder to separate Model, View, ViewModel or create new project for each? Which one is good practice? I downloaded sample project, some of project have separate folder for it and some of have separate project for each. I referred this link.
But this isn't clear my doubt. I am asking whether creating new projects for Model, view and viewmodel is good practice or creating new folder?
This is a duplicate question, as you can find the answer here by Sheridan to be most helpful.
Basically you need to determine what the overall size of your project is going to be. If you plan on reusing pieces, you might want to to multiple projects and different levels of folders. This also goes for if you plan on providing parts of your application as an API, then you will probably want to use multiple projects.
For beginners, I would suggest you start small and put everything in one project. To learn MVVM, don't focus on the project structure rather how WPF and MVVM work. Solution structure can always be revisited after you've understood how MVVM is working.
EDIT
The answer is no, you never need to create folders or separate projects for your project. Just realize that creating new classes under a different folder will also use that path as a namespace. So if you create a ViewModels folder and add a class to that folder you will see namespace WpfApplication1.ViewModels at the top. This also means that you will have to pay attention to locations of namespaces in your XAML files. If you wanted to reference a type in your ViewModels folder in a XAML file, you will need to do something like <xmlns:vm="clr-namespace:WpfApplication1.ViewModels">. The downside is if you have folders in ViewModels you need to reference that namespace in your XAML also. So if there was ViewModels > Basics, you would need both namespaces in XAML since you can't reference all sub-dirs in one xmlns declaration.
<xmlns:vm="clr-namespace:WpfApplication1.ViewModels">
<xmlns:vmBasics="clr-namespace:WpfApplication1.ViewModels.Basics">
The alternative is using folders and renaming the class namespaces to just plain old namespace WpfApplication1 then you would just need a single xmlns declaration and can access all types in your application.
<xmlns:app="clr-namespace:WpfApplication1">
So, don't complicate things if they aren't needed; and typically nothing in the learning stages will be so complex it needs multiple projects. Folders are optional, but understand the side effects/workaround if you use them.
This will really depend on your use case. Do you have a scenario in which your views, view models and models may be separately reused in some other project? What i mean by that, for instance, do you have a scenario where you would use only your models in some other project. If yes, then it makes sense to create separate projects so they may be reused. If that is not the case however, it is better to keep them all in one project.
Folders are only for creating the Structure and for easy Identification. It is really not necessary to have Folders for View and ViewModel.
I would normally create folders each for view, ViewModel etc. Then I would give descriptive names to views and viewModels classes. If you have several pages I would suggest having sub folders. All goes in one project. But this is my preference.
eg:
View>Sales> WelcometoSalesPageView.xaml
ViewModel>Sales> WelcometoSalesPageViewModel.vb
Related
I'm trying to understand how to do an Asp.Net Core application (3.0) looks like a Screaming Architecture folders and files conventions.
I read about it but and started with an empty project. The folders are:
Controllers
Views
Models
I want to make the web application working like
Customers/Controllers
Customers/Views
Customers/Models
Is it possible?
Thanks in advance.
Both controllers and models are referenced by namespace, so their physical file locations have no bearing on anything. Controllers are dynamically loaded regardless of where they are in the project or even if they're in the project at all (i.e. a controller from a referenced library will automatically be loaded). Models are entirely code-based, and you'd just add a using statement with the namespace of the model(s) to access them in any other piece of code.
Views, however, are very much based on the filesystem, and changing the main folder they're in from just Views or Pages directly in the project root will cause the convention-based view loading to fail completely. You can always add additional view search locations, such that it will look in /Foo/Views and /Bar/Views, etc. but that's really not recommended.
All that said, though, there is a concept of areas, and you can break down your controllers, models, and views that way. You'd simply have to have:
Areas/Customers/Controllers
Areas/Customers/Views
Areas/Customers/Models
In other words, the Areas prefix would be mandatory.
I am trying to apply the onion architecture by J. Palermo, but I have a few things I am struggling with.
I have a few parts and I don't know exactly where to put these.
I have a plugin engine which reads a directory and determine what things to load en to do
Have some resource files with translations which are used in several projects. Where should I put these files?
I have some attributes which are used throughout the system. Where to put these?
I also have two 'base' controllers, some default results and views. Where should I put these?
All those items are used in several projects so I want to put the items at a central point.
My current solution structure looke like this:
Project.Core (contains the domain objects and interfaces of the repositories)
Project.Infrastructure (is the implementation of the core)
I am using MVC2.
I don't think it's something that the Onion architecture would solve by itself.
What I would do, is to put all these items in one or several projects, within another solution and build Nuget packages allowing me to deploy them everywhere I would need them.
This way I would have deployed items like your base controllers in your MVC project and plugin/translation stuff in your Infrastructure project.
That way, whenever you'll need to have those elements available in your newly created projects, you'll just have to deploy the package again.
Those items will become independent, stored in a central point (a new sln) and will have it's own release cycle!
I have a directory structure to store the source files. Is this the good practice to
name the naming space according to the directory structure?
Like
Models\model.cs
Data\data.cs
One is defined in namespace Models
One is defined in namespace Data
Yes, that's the typical approach, and it's also one that's supported by tools such as ReSharper.
The difference between this and the Java approach is that you don't add directories all the way down from the top - just from the default namespace for the project. So for example, suppose we were creating Foo.Bar.Baz.Model and Foo.Bar.Baz.Data, the C# and java solutions might be:
C#:
Foo.Bar.Baz
Foo.Bar.Baz.csproj defining a project with default namespace of Foo.Bar.Baz
Model\
SomeModel.cs
Data\
SomeData.cs
Java:
src\
foo\
bar\
baz\
model\
SomeModel.java
data\
SomeData.java
yes is the usual practice, but you also put the project name before the directory name so you will have: myclasslibraryname.Models.Model and myclasslibraryname.Data.Data
Yes. It is a common practice in Java (at least, the source code I've looked at for big projects has almost always been structured this way). Not as common in C# from what I've seen, but there's nothing keeping you from doing it, and it helps you find the code a lot faster.
You'll probably want a deeper namespace hierarchy than just one level though. It is common to preface it with your organization or group name, the project name, the library/program name, then code architectural names (like Model, View, Data, etc). Whatever makes the most sense for whatever scope the source code of your project will live.
Generally I think it is a good practice. When you do it in such a manner, while going through the code, you can generally associate or easy to locate and get to know where your code file is coming from.
This is also a good practice in terms for maintaining the code. Some new user comes in, he can just see the namespace and identify where the code files are located or needs to be searched.
I don't know really if this is good or not.
But I name it like this.
I defined categories for the different modules.
Like this:
Company.Common
Company.Common.Web
Company.Windows
Company.Windows.Services
Common represent a directory. Inside it I created a solution with VS2010.
Inside the solution I create a project for each part and therefor the subdirectories for the project and if the project is complex, more sub dirs for the existing classes inside the dll.
There I have a good overview in all views (dir - view and project view - code view ).
This is a convenient convention for many projects, and one which some tools support or expect.
However, this isn't the full story. Although it's a good default, I don't think it should be regarded as inviolable best practice, because there are some circumstances which might motivate doing things another way. Additional factors to think about include:
Unnecessary namespace proliferation
and deeply nested namespace
hierarchies can be a pain for users
of your types. In a large library you
may want to start organising the
source code files into some folder
structure before you feel the need to
impose multiple namespaces on your
clients.
Related to this, namespace
hierarchies in .NET are supposed to
work such that dependencies between
types go from child namespace to
parent, not the other way around.
This isn't always the natural way to
organise source code into
folders/directories. For example, one
often sees people creating namespaces
such as MyNamespace.Foo.Common
containing utility types used both by
types in MyNamespace.Foo.Bar1 and
those in MyNamespace.Foo.Bar2. It
seems sensible to them at the source
code organisation level, but it
breaks the namespace dependency
convention.
Sometimes you may want to provide
additional functionality by adding
some types to a library namespace by
distributing a supplementary assembly
rather than releasing a completely
new version of the full library
assembly. It's likely to be more
convenient to keep source code files
for the respective assemblies
separate from each other in the
repository, rather than to store them
together just so as to keep all types
for the namespace in the same folder.
In short, I'd say follow the usual practice unless you have a good reason to do otherwise. But don't let it deter you, if you have a good reason to make use of the fact that Namespaces can provide a grouping of types completely orthogonal to their grouping into deployable assemblies and the source code which builds those.
I've written a simple desktop application with C#/WPF and I'm now looking to create another, larger application which will share much of the functionality. I'm thinking that I should create three separate projects: one containing the shared code, and one each for the two apps.
My problem is that I'm not entirely familiar with .NET/WPF so I don't know if there are some best practices for this sort of thing. Can anyone offer some good sources of information, example projects or just some brief advice?
Edit: To put a little more detail on the scenario, the first application is a specialised editor and the second application is taking this file editor and wrapping a project model around it to create a sort of basic IDE.
Honestly it depends on what level the code you intend to share is. For instance, it's entirely plausable to put all of your business logic code into one project/class library and maintain it independantly, but mixing biz logic with WPF custom controls should be STRONGLY discouraged. Think about the layers of abstraction you are modularizing, and the dependancy heiarchy you are introducing and refactor accordingly.
Edit:
In response to your above changes I suggest the following: The logic and DAL associated with the above should be pushed into a project as seperate namespaces. The visual elements (the view, viewmodel) should most likely be moved into a seperate project and namespace set as well. Once you can merge these together and launch them from an exe that contains a host window and a UserControl for the rest of your hosted visual content, you can then probably move forward with integration into your larger IDE project. The key here is:
Visual Layer and View Logic -> Editor.Visual.dll
Biz Logic & Data Access -> Editor.Core.dll
I hope this helps.
In the MVC folder structure, where should general class files reside? For example, I have a class that determines the right DataContext to use, so I'm not reinventing the wheel in each of my controllers. Should it live in the Controllers folder even though it's not a controller? Should it be with the Models because it's database related, even though it's not a model? Possibly the Views\Shared folder? Or is Content the catch-all folder for that kind of stuff? I'm sure I could put it anywhere, but I was wondering where the "right" place is.
It's not a controller, content or a view, so don't use those. It sounds most closely related to your model, so you could put it in model under a subfolder called "Helpers" or "Utility" or some such. Or you can add another top level folder called Services and put it there. That's where I put all my app logic, the middle man between the controllers and the model.
If you look at Rob's MVC Storefront: Separate class library project (like Commerce.MVC.Data)
If it could be useful by itself (think of a command line tool built around it), put it in the Models folder. If it is used only as a helper for controllers, put it in Controllers folder.
It really depends on what it does, if it accesses data it should be in the Data Access Layer, otherwise you can put it in the controller folder.
Have a separate DataAccess assembly, make that class internal and call it DataContextFactory.
dmajkic,
Why separate it out into its own area? If its BLL code it should be in the controller folder, if its DAL related item it should be in the Model. I can understand if a project gets huge and you want to create some subfolders, that shouldn't be an issue. But placing code in another tier really defeats the purpose of MVC don't you think?