separation-of-concerns | 易学教程

Doing dependency injection using monad stacks

阅读更多关于 Doing dependency injection using monad stacks

问题 I'm trying different approaches to do what is sometimes known as dependency injection. For this I've elaborated a simple example of a weather app, where we want to fetch the weather data (from a web-service or from a hardware device), store the weather data (could be a database or simply a file), and report it (either print it to screen, or speak the weather). The idea is to write a program that uses some fetch , store , and report functions, whose implementations can vary. I've managed to

ViewModels and rendering

阅读更多关于 ViewModels and rendering

问题 In several sample projects, I've seen ViewModels being used to convert data objects into strings, for use in the View. The ViewModel will typically have a constructor that receives one parameter - a data object. The constructor will then populate various properties of the ViewModel (mostly strings and ints). This prevents any complex logic from occurring in the View. At first glance, this seems like a good idea to me, as it more fully enforces separation of the View from complex logic. For

Accessing Database Entities from Controller [closed]

阅读更多关于 Accessing Database Entities from Controller [closed]

问题 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 . tl;dr In a good design. Should accessing the database be handled in a separate business logic layer (in an asp.net MVC model), or is it OK to pass IQueryable s or DbContext objects to a controller? Why? What are the pros and cons of each? I'm building an ASP.NET MVC

EmberJS: Good separation of concerns for Models, Stores, Controllers, Views in a rather complex application?

阅读更多关于 EmberJS: Good separation of concerns for Models, Stores, Controllers, Views in a rather complex application?

I'm doing a fairly complex emberjs application, and tying it to a backend of APIs. The API calls are not usually tied to any particular model, but may return objects of various types in different sections of the response, e.g. a call to Events API would return events, but also return media assets and individuals involved in those events. I've just started with the project, and I'd like to get some expert guidance on how best to separate concerns to have a clean maintainable code base. The way I am approaching this is: Models : essentially handle records with their fields, and other computed

Accessing Database Entities from Controller [closed]

阅读更多关于 Accessing Database Entities from Controller [closed]

tl;dr In a good design. Should accessing the database be handled in a separate business logic layer (in an asp.net MVC model), or is it OK to pass IQueryable s or DbContext objects to a controller? Why? What are the pros and cons of each? I'm building an ASP.NET MVC application in C#. It uses EntityFramework as an ORM. Let's simplify this scenario a bit. I have a database table with cute fluffy kittens. Each kitten has a kitten image link, kitten fluffiness index, kitten name and kitten id. These map to an EF generated POCO called Kitten . I might use this class in other projects and not just

How does Clojure approach Separation of Concerns?

阅读更多关于 How does Clojure approach Separation of Concerns?

How does Clojure approach Separation of Concerns ? Since code is data, functions can be passed as parameters and used as returns... And, since there is that principle "Better 1000 functions that work on 1 data structure, than 100 functions on 100 data structures" (or something like that). I mean, pack everything a map, give it a keyword as key, and that's it ? functions, scalars, collections, everything... The idea of Separation of Concerns is implemented, in Java, by means of Aspects (aspect oriented programming) and annotations. This is my view of the concept and might be somewhat limited,

When to use JavaScript template engines?

阅读更多关于 When to use JavaScript template engines?

Here is an example of JavaScript template from Ben Nadel's demo single page long-lived AJAX application taken from: [source] <script id="contact-list-item-template" type="application/template"> <li class="contact clear-fix"> <div class="summary"> <a class="name">${name}</a> </div> <div class="actions"> <a href="javascript:void( 0 )" class="more">more</a> | <a href="#/contacts/edit/${id}" class="edit">edit</a> | <a href="#/contacts/delete/${id}" class="delete">delete</a> </div> <dl class="details clear-fix"> <dt> name: </dt> <dd> ${name} </dd> <dt> phone: </dt> <dd> ${phone} </dd> <dt>

Generating Interfaces from entity framework database first auto-generated code

阅读更多关于 Generating Interfaces from entity framework database first auto-generated code

I am using MVC3, C# 4.0 and Entity Framework in Visual Studio 2010. I am generating my edmx and Designed.cs files from a database. I am then generating interfaces from the entities in the Designer.cs file as part of my nLayer structure. The original code is public partial class DataEntrySummary : EntityObject which then becomes public partial class DataEntrySummary : EntityObject, Mb.Interface.IDataEntrySummary My concern is that when the database changes (and it will) and I regenerate the edmx files I will lose all the interface definitions. Is there a better way of achieving the same result

ASP.NET MVC - separating large app

阅读更多关于 ASP.NET MVC - separating large app

I've been puzzled by what I consider a contradiction in terms: ASP.NET MVC claims to be furthering and supporting the "separation of concern" motto, which I find a great idea. However, it seems there's no way of separating out controllers, model or views into their own assembly, or separating areas into assemblies. With the fixed Controller , Model and View folders in your ASP.NET MVC, you're actually creating a huge hodge podge of things. Is that the separation of concerns, really?? Seems like quite the contrary to me. So what I'm wondering: how can I create an ASP.NET MVC solution that will

Difference between Single Responsibility Principle and Separation of Concerns

阅读更多关于 Difference between Single Responsibility Principle and Separation of Concerns

What is the difference between Single Responsibility Principle and Separation of Concerns? Single Responsibility Principle (SRP)- give each class just one reason to change; and “Reason to change” == “responsibility”. In example: Invoice class does not have a responsibility to print itself. Separation of Concerns (since 1974). Concern == feature of system. Taking care of each of the concerns: for each one concern, other concerns are irrelevant. Hiding implementation of behavior. From here . Matthew Groves Separation of Concern vs Single Responsibility Principle ( SoC vs SRP ) From the linked