Hot answers tagged

7

Personally I'd do something like this public class AllProfilesViewModel { public AllProfilesViewModel(IEnumerable<FullUserProfile> allProfiles) { _allProfilesList.AddRange(allProfiles); } private List<FullUserProfile> _allProfilesList = new List<FullUserProfile>(); public IReadOnlyCollection<FullUserProfile&...


5

First off: I know that best practice is that the property for the List should be a IEnumerable interface. Not necessarily. IEnumerable is a read-only, sequential-access-only collection interface. There are many cases in which that's exactly what you need, but plenty of other cases where it isn't. Depending on your use case, ICollection, IReadOnlyList, ...


4

So, MVC is an architectural style/pattern that's centered around GUIs/presentation, and it's about (a) controlling the coupling (interdependencies) between the presentation logic (stuff related to the UI) from the business/domain logic (the main thing your application does), and (b) in some variations, also about controlling what's going on within the ...


4

Asking the difference between Entity-Component-System and Model-View-Controller is like asking about the difference between a hammer and a saw. They are both tools in your toolbox, but used for different things. With ECS and MVC, they are both software design patterns, but solve different problems. Everything else about them is completely and utterly ...


4

If the variables $flow_curve, $curves, and $graphs belong to a bigger "something", give that "something" a name and create a class from it (maybe it is the Graph class you mentioned? Or maybe some GraphCollection?). Find an abstraction which suits your needs best. Then the code could be naturally placed in the constructor of that class - and that is the name ...


4

In my opinion, you should add another abstract layer (for example, a repository) between the model and the client using it. I think it's better if we keep the model clean from infrastructure related code (quering database, calling API, ...). The following is my pseudo code, not in any specific language. The repository interface interface ...


4

The MVC design pattern does not specify the mechanics involved in choosing which view to render. Both ways are "MVC". If you are rendering a collection of books, the controller renders a single view responsible for rendering a collection of books. If the controller renders a single book, it needs to render a single view for a single book. They are two ...


4

Yes. You need a unique Id for these things and the DB id fits the role. Ideally the unique id is independent of the database though. Have a GUID on your business object and use that as the DB key rather than the other way around. But 99.9% of the time its going to be a purely conceptual difference.


3

Having a Model and a ViewModel promotes separation of concerns by allowing your Model to work independently from the rest of your system. Have a look at the following architecture: {Database} --> {Data Access Layer (DAL)} --> {Model} --> {ViewModel} --> {View} The arrows show the direction of dependency travel. The principle illustrated here ...


3

Sure, this is perfectly valid. It all depends on the specific use case. If there are multiple applications which utilize the web service then it makes sense to split that data access layer out into something that multiple applications can reach as opposed to implementing it directly in the MVC site. As far as the difference between using EF and stored ...


3

In MVC, model is the instance, naturally. Model, view, and controller are objects that communicate with each other within a user interface. However, the word model is ambiguous. It's often used to describe domain objects but this does not always match the MVC model. For example, in the Smalltalk-80 browser (where MVC was invented and first used) the domain ...


2

I'd suggest the first approach because: Constructor is not a good place for accessing slow Internet network. Programmers generally expect a constructor be returned virtually instantly. What happen if the Internet connection is down, how are you going to report the errors to users in a constructor? In your first approach, you could easily show a popup box if ...


2

It's 4 years later and I just found this question again, and I have what is, to me, the answer. Depending on your application and it's specific needs, your domain/transaction database and your reporting can be separate "systems" or "engines", or they can be serviced by one system. They should, however, be logically separate - which means they use different ...


2

I'm trying to avoid having my controllers get too fat That's admirable, but if you are replacing a 1-line logging method in the body of each Action method with a 1-line ActionFilter attribute, then you aren't reducing the fatness of the controllers at all. As you've noticed, the problem with ActionFilters is that you don't have access to the full range of ...


2

The Model-View-Controller pattern is a UI pattern that follows a few basic principles: The View is a User Interface, a thin veneer in front of the Controller. The only logic that should be in the View (i.e. "Code-Behind") is that logic which pertains directly to interacting with the user. The Controller is a thin veneer in front of the Model. It acts as a ...


2

I am one of those who think that Singleton is an anti-pattern, so I'd say I like your implementation best and I'd also recommend your team to take one existing MVC framework rather than using up time reinventing a (usually worse) wheel. Now that this is out of the way, I'll actually answer the question. Option 2 looks better. DRY is important here because ...


2

Option #2 is fine. It works even if the presenters/views are not hierarchically organized, and the "global option" may affect different components than just panels in your application. In fact, the different views or presenters don't have to know each others and stay completely independent from each other. We implemented a similar approach in a standard ...


2

So, theory first: Generally speaking, Authentication and Authorization are cross cutting concerns which should not be part of the Models. In MVC the controller is the "entry point" for all actions, user generated or not. A background process which is part of the same application should call a controller. In practice, it sounds like you are trying to cram ...


2

The data in your step 1. is the model. The "model" in MVC does not refer to some MVC-specific component but rather to any data structure or object you plug into the viewmodel or directly into the view+controller.


2

I highly recommend separate your project as layers and have a Service Layer that can be used by your many projects such as MVC and/or Background Jobs and you can add this Authorization Service to Service Layer. So you can call this Authorization Service Layer. This way, you don't need to extend Authorization to the Model layer because your other entry-...


2

if in a monolith MVC application (i.e rails) you have other entry-points than just the Controller? I.e background jobs, or the model interaction? Consider workers (jobs executors) as actors of the system. Give them an identity in the security service so that they can engage with it like any other actor. Grant them with special privileges if necessary. ...


2

Looking at your code, if you have any requirement to have a unit test cover the processRequest method, without dependency injection it will be impossible for you to provide a mock object for MyObjectClass in your first example. If MyObjectClass interacts with anything (such as making an HTTP request, write / read from a file, save / read stuff to or from a ...


2

While I think @Christophe's answer is the simplest solution (and simplicity often prevails over everything else), I think there is, at least, one more alternative. If OrderController is basically the same for all three contexts but for some specific behaviour, I would evaluate the possibility to make these specific behaviours parametrizable. In other words, ...


2

I think this is the main difference between MVC and MVVM approaches. In MVC you have the controller populates the ViewModel which is essentially just the a struct of the various data the view needs In MVVM you don't have a controller, so all the logic goes in the ViewModel, which is now a 'proper' class with methods and everything. If you are in the ASP ...


2

It all depends on how you configure your server. The slightest mistake could give anyone the ability to read files as text. Resources and .cs files included. Storing users' passwords plain text is always a bad idea. You should use existing algorithms which would create, for a given password, a salted hash. If an intruder gets (read-only) access to all your ...


2

As talking about content-type headers only makes sense in the context of a remotely rendered view, as it typical for web-applications, I will assume that is the case here as well. The content-type header, as well as other headers, are part of the communication mechanism for transferring the View information from the back-end part to the front-end (view ...


1

[By memory. I don't have the book in front of me at the moment.] Martin Fowler in his book Patterns of Enterprise Application Architecture (PoEAA) discusses the Document-View, MVC, MVP(SC), MVP(PV), MVVM, and other MVx patterns. He remarks that it's easy to spot the divide between the responsibilities of the View and the rest. Everyone easily arrives to ...


1

Presumably you're talking about ASP.NET Core. Because the last major release of ASP.NET MVC is over 8 years old. I hope you're not replacing a dead technology with one that is on life support. What you need to keep in mind is that monster has a decade of decisions, behaviours and subtle side effects that could be a nightmare to replicate in a new code base. ...


1

At the end of the day, you are doing a rewrite of your application. Whether it's little by little, or all at once, the application you end up with is completely different from what you received. There are no automated ways to make the changes you want. Once you come to grips with that fact, you have to decide what you want to maintain in the future. ...


1

There is no automated migration path from Webforms to MVC. You will find several articles on the internet about how people have done it manually, but each involves rewriting the code, so the process that worked for them may not fit your code. Personally I would advise either not doing it at all (Refactoring rarely pays off). Or writing a "version 2" from ...


Only top voted, non community-wiki answers of a minimum length are eligible