I am trying to implement architecture similar to one presented in https://www.jstage.jst.go.jp/article/transinf/E101.D/2/E101.D_2017EDP7165/_pdf
using Microsoft's CNTK framework. So I need to add inputs to one or more hidden layers which do not represent the outputs from previous layer but are externally defined.
I've tried by splicing standard layer and these additional inputs into a single layer, but then I obtain a layer with multiple inputs. And I am also not sure how can I make partial connection of two consecutive layers in CNTK.
I have looked the documentation but haven't found any function that could help me. Is this possible to implement with CNTK?
code = C.input_variable()
input_tensor = C.input_variable()
denseout1 = Dense()(C.splice(input_tensor, code, axis=...))
denseout2= Dense()(C.splice(denseout1, code, axis=...))
** I answered here so that anyone looking at this gets help too.
Related
I am still new to ASP.NET MVC world and still try to learn best practices and
best architecture patterns. Here comes one the things where i can't decide on my own and need community support:
I am not sure where I should put all of my business logic and how much of it could be in the controller. I know best would be if ALL business logic is implemented in my service layer. One of the biggest concerns I have is that I want to show not only simple model errors in the view I also want to show error messages in different places when more complex business validation was made. But when I have a service layer which does the full validation and that is completely decoupled from web layer (controller, views) then it makes more complex passing all the errors and assign to the correct view properties.
Which of the following options make more sense or is there no general recommendation?
Just high level examples. no correct syntax or naming :-)
Option 1:
Controller.Action(){
if(ModelState.IsValid){
ServiceLayer.IsAllowedMoreComplexCheck();
ServiceLayer.IsBusinessModelValidCheck1();
ServiceLayer.IsBusinessModelValidCheck2();
ServiceLayer.IsBusinessModelValidCheck3();
ServiceLayer.DoAction1();
ServiceLayer.DoAction2();
ServiceLayer.DoAction3();
ServiceLayer.SaveChanges();
}
}
Option 2:
Controller.Action(){
if(ModelState.IsValid){
ServiceLayer.IsAllowedMoreComplexCheck();
ServiceLayer.DoAllActions();
}
}
ServiceLayer.DoAllActions(){
ServiceLayer.IsBusinessModelValidCheck1();
ServiceLayer.IsBusinessModelValidCheck2();
ServiceLayer.IsBusinessModelValidCheck3();
ServiceLayer.DoAction1();
ServiceLayer.DoAction2();
ServiceLayer.DoAction3();
ServiceLayer.SaveChanges();
}
Option 3:
Controller.Action(){
if(ModelState.IsValid){
ServiceLayer.IsAllowedMoreComplexCheck();
ServiceLayer.IsBusinessModelValidAllChecks();
ServiceLayer.DoAllActions();
}
}
ServiceLayer.DoAllActions(){
ServiceLayer.DoAction1();
ServiceLayer.DoAction2();
ServiceLayer.DoAction3();
ServiceLayer.SaveChanges();
}
there are also few more options... but just to indicate what i am thinking about.
Every feedback is welcome.
Thanks!!!
Simon
As per my experience keep your business logic in service layer because I think by this way you keep the loose coupling motto of MVC intact. Yes it's true you need some extra code to handle validation and error but I think for a good enterprise level application you must design good architecture that must survive for a long time.
Best place to play with MVC is play with its pipeline and provide your custom logic for pipeline components.
For simple implementation you can do following things:-
You can create custom action attributes to do validation.
For error handling you can create custom error action attribute and provide your own OnException() method implementation by implementing IExceptionFilter interface in your custom error.
Refer this link for error handling in detail.
I am not sure where I should put all of my business logic and how much of it could be in the controller.
No business logic should be in controller. Now, what do you mean by putting in Service layer. Service layer should only handle purpose of servicing, Business logic should be in Business logic layer and should be independent of service layer too (what if you want to make changes to the way your service layer serve?).
One of the biggest concerns I have is that I want to show not only simple model errors in the view I also want to show error messages in different places when more complex business validation was made. But when I have a service layer which does the full validation and that is completely decoupled from web layer (controller, views) then it makes more complex passing all the errors and assign to the correct view properties.
In long run that will pay off. Error handling, exception handling should be thoroughly thought of when developing an application.
Want to improve this post? Provide detailed answers to this question, including citations and an explanation of why your answer is correct. Answers without enough detail may be edited or deleted.
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 have a drop down list that displays values from a table to the end user. I would like to have these values be sorted alphabetically.
According to proper MVC design, at what layer should I place my sorting logic: the model, the view, or the controller?
EDIT: In response to LarsH's question, "Do you mean code that determines what sort order is desired? or code that performs the sort?", I was originally referring to the code that determines what sort order is desired.
Who controls the sort order?
(From Wikipedia)
1) Natural order within the data itself:
The order is part of the Model, so it should go there. A raw pull of "all data" would return the data in the sorted order, and there is no interface to choose the sort order.
2) The user should control how they see the data:
The View would provide an interface (such as ascending/descending arrows) that interact with the Controller, and the Model understands the data well enough to do the requested sort on the data. However, a raw pull of the data doesn't necessarily have to be sorted, unlike in (1).
In either case,
The View doesn't understand that there's a sort going on, other that the ability to show which sort direction has been chosen. Don't put the logic there.
Small caveat
The sorting functionality could go purely in the View, under one circumstance (that I can think of offhand; there may be more):
A "dumb" sort where all the data is already in the view and it doesn't have to use any domain knowledge to do the sort. Very simple string or number comparison, for example. This is not possible in, for example, search results on a webpage when results are likely to be split across multiple pages.
(Note: this quote and citation is taken from #dasblinkenlight's answer, but we disagree on our interpretation of it. read his post and make up your own mind).
According to MVC description,
A controller can send commands to its associated view to change the view's presentation of the model (for example, by scrolling through a document). It can send commands to the model to update the model's state (e.g. editing a document).
Sorting logic (e.g., the sorting comparator/sorting algorithm) belongs in the model since it contains business rules and state data. Since altering the way the model data is sorted falls squarely into the "change the view's presentation of the model" category, the controller is responsible for "doing the sorting" by calling the model.changeSortedState() method.
According to MVC description,
A controller can send commands to its associated view to change the view's presentation of the model (for example, by scrolling through a document). It can send commands to the model to update the model's state (e.g. editing a document).
According to this, sorting logic belongs in the controller, because altering the way the model data is sorted falls squarely into the "change the view's presentation of the model" category.
EDIT: To clarify multiple misunderstandings voiced in the comments, the "sorting logic" is not the code that performs the sort; it is the code that defines the sort. The sorting logic compares individual items to each other to establish an order (e.g through an instance of IComparator<T>) or contains logic that constructs an object to be used for ordering by an external system (e.g. through an instance of IOrderedQueryable<T>). This logic belongs in your controller, because it needs knowledge related to the "business" side of your application. It is entirely sufficient to perform the sort, but it is separate from the code that actually performs it. The code that sorts may be in your view, in your model, or even in the persistence layer that backs your model (e.g. your SQL database).
None of the above. Sorting is business logic, and business logic doesn't belong in any of the three. Not every piece of code in your application will be a model, view, or controller.
What I generally do in my MVC apps is I have a service layer that performs all the business logic. The methods in the service layer should have a clean, simple API with well named parameters. You can then invoke those methods from your controller to manipulate the data in the models.
In that sense, the sorting is "in the controller", but the code itself that does the sorting should not be implemented in the controller, only invoked from there.
Definetly not the controller: It sends messages to view and model but should do as little work as possible. If the user can change the sorting that request gets handled by the controller by informing the model or the view about it.
Maybe the View if it is a pure View thing. If the Application works just as well without sorting then the sorting is just part of the representation and should go in the view.
If the ordering is inherent part of the domain it should go in the model.
Views are the part of MVC which is supposed to contain presentation logic.
Model layer is where business logic is contained.
Controllers only change the state of both, based on user input.
So the choice is - do you think that this is part of the domain business logic or presentation logic.
If you were implementing a proper MVC Model2 or classical MVC pattern, then I would say that the ordering of data provided by the model layer should be triggered by the view's request to the model layer. View asks for ordered data, model layer provides it.
But, since you are using ASP.NET MVC's interpretation of MVC pattern, which is a bit different then your standard MVC - the ViewModel instance should request ordered information from the model layer (for some reason ASP.NET framework thinks that templates should be called "views" and views should be called "viewmodels" .. it's strange).
I would usually do it in the controller to remain in line with the pattern as per the other answers. See below for reasoning.
I've been mulling this over and reading the answers and related material and pragmatically speaking I would say it would depend on your application for instance:
Is it a medium/large application and/or has multiple UI's associated with it (i.e. a Windows App, Web interface and Phone interface).
In this case I would probably construct a service layer and put it in
the business object and then call the appropriate method from the
controller.
If its a well defined single UI website and you're using something like EF Code First and you do not have or have no intention of creating a service layer and plan on using a simple out of the box Extension method to acheive it:
In this case I'd probably put it in the controller as pragmatically
its the best fit with regard to time/budget.
If its the same as the above BUT cannot be implemented with an out of the box extension method.
I may well choose to pop it in the Model class (if its truely bespoke
to that single type) as it would be more appropriate here than in a
controller. If the sort could be applied to more than one class then
I'd implement it in an extension method and then call it in the
controller.
To sum up:
Dogmatic answer: Service Layer
Pragmatic answer: Usually the controller
I would suggest sorting data from a table-data that is small enough to be useful in a dropdown list-should come from the DB already sorted via the query. To me, that makes the model the place the sort is applied.
If you are determined to do the sort by hand, I think there are good arguments for using either the model or controller as your preferred spot for logic. The limitation would be your particular framework. I prefer to manage data solely in the model. I use the controller to marry data(model) and presentation(view) as I've been (self)taught.
Whilst I agree in principle with the idea that sorting is Business Logic because by breaking it down to it's origin you would end up with something like "The client would like the Product page to display with the images sorted by date" then it becomes clear that the sort order for data is typically not arbitrary - even if there is no sorting as that's still a business decision by omission (an empty list is still a list).
BUT... These answer don't seem to take into account the advances in ORM technology, I can only talk in relation to the Entity Framework (let's avoid an argument about whether this is true ORM, that's not the point) from Microsoft as that's what I use, but I'm sure other ORMs offer similar functionality.
If I create a Strongly Typed view for a Product class using MS MVC and the Entity Framework and there is a foreign key relationship between the Product and Image table (e.g. FK_Product_Image_ProductId) then I would out-of-the-box be able to quickly sort the images during their display using something like this in the view:
#foreach(Image i in Model.Image.OrderBy(e => e.DisplayOrder)){ //etc etc... }
There was mention of a specific Business Logic layer, which I also use to perform 80% of my business logic, but I'm not going to write sort functionality into my Business Logic layer that mimics something that comes out-of-the-box from the Entity Framework.
I don't think there's a correct answer to this question, other than to say that; you should abstract complex business logic where possible but not at the cost of reinventing the wheel.
Assume that you have MVC website, WebForms website and a mobile application.
If you want sorting to be consistent between these presentation layers, then I'd say sort outside of the presentation layer. Service would be a good candidate.
Otherwise, I would store that logic in a view model. Why? Because it'll be reusable and easily testable.
Out of the three you have listed, I would say that it belongs in the controller. I don't really like placing this sort of logic in the controller, though. I usually create a service layer that the controller communicates with that will be responsible for communicating with the data store and handling sorting logic. For small applications it is fine sitting in the controller, though.
This is a question asked with the asp.net in mind, but since somebody did mention Rails, I thought it would be interesting to consider the problem in that context. In Rails, it is natural and pretty common to perform the sorting along with the retrieval as a controller action, since the framework and ActiveRecord/ActiveQuery api provisions for it. On the other hand, it is possible to define some sort of custom sort order for static items and put that in the model to be used by the controller, so the model can play a part in the sorting logic even though it does not carry out the operation directly. Whatever it is, it can be safe to say that putting the sort logic in the view is generally frown upon.
I'm slightly amused that some answers are absolutely against putting the sort in either the controller or the model, and I find them too pedantic for my taste, but I suppose it depends on the nature of the framework used and the usual conventions associated with it. I also agree with Bill K's comment that having the separation in the first place is more important.
I hope this isn't too vague, but I'm stuck on a problem that has put me in an Unfortunate Position.
I'm Flash developer getting my feet wet with with AS3 and am trying to build an interior decoration tool for a client. My thinking so far has been: create the basic user interface, get the screen flow down, and then finally use a couple of simple arrays to store user selections and stuff like that.
Naturally my 'couple of simple arrays' is totally inadequate to model the many user decisions that my program has to take into account. So I find myself trying to create an enormous, multi-dimensional array with several layers of nesting and before Panic sets in.
Here's an example of my thinking for the 'bedding' component of the application in pseudo ActionScript:
bedding['size'] = 'king':String
bedding['cover'] = cover:Array
cover['type'] = 'coverlet':String
cover['style'] = 'style_one':String
cover['variation'] = 'varation_one':String
cover['fabric'] = fabrics:Array
fabrics[0] = 'paisely':String
fabrics[1] = 'argyle':String
fabrics[2] = 'plaid':String
cover['trim'] = trim:Array
trims[0] = trim_pair:Array
trim_pair['type'] = 'trim_one':String
trim_pair['color'] = 'blue':String
trims[1] = trim_pair:String
trims[2] = trim_pair:String
cover['embellishments'] = embellishment_pair:Array
embellishment_pair['type'] = 'monogram':String
embellishment_pair['letters'] = 'TL':String
... keep in mind that this is just a fraction of what goes into bedding and there are several other of these kinds of arrays that would go into a room like flooring and walls and funture... all equally complex. And I'll need to frequently access different combinations like, how many options under bedding have no value associated and things like that.
So, I realize I'm out of my league and am going to get hurt on this, but I'd like to try to get this right so that I get better and any help you guys can provide is great.
My questions are:
1) Could it be that using nested arrays like this actually isn't such a bad thing and I should just stick it out? That would suprise me, but I want to make sure I'm not already on the right path.
2) If not, where do I go from here if I want to do this right?
Off the top of my head I feel like I could maybe make everything class based. So my sheets are a class and beds have instances of sheets and rooms have instances of beds... etc. It think it would be complicated but might be the way to go.
Or maybe, I go the XML route and store all of the room options in nested blank XML nodes that a user then populates as they move through the application.
These are my thoughts but I'd like to hear what more experienced members of the community say.
Thank you so much for your help!
My suggestion would be to use a strongly typed model. Look into using collections and value objects to store and retrieve data. A collection could be a class that wraps an Array and provides a clean interface for fetching the value objects that it stores. Value objects are simple objects representing data that can be assembled in various ways to create more complex collections. Value objects can also be passed around to transfer data to various parts of an application. The advantage to using collections and value objects is that your code will be ( potentially ) more explicit and over-all easier to read than if you went with a dynamic approach. For some, the downside to this approach is that you end up with too many classes. Personally, I prefer working with many small to medium size classes versus one monolithic class.
If you are not familiar with the concept of value objects: http://en.wikipedia.org/wiki/Data_transfer_object.
AFAIK, AS3 is not well suited to the type of complex data model you're trying to create.
You need to completely decouple the UI/Flash tier from your "inventory" system. The UI should be completely abstract, with no knowledge of, or coupling to, your data schema or content. This could be accomplished with a middle-tier webservice-styled system that handles all the business logic around searching/retrieving/updating your data.
Store everything your UI needs to handle presentation-side rendering in your product metadata. This will allow you to add new products and types without having to update the UI every time new products are introduced. For example, if a product comes with an image, store a URI to the image with the product record and load it on demand. You could extend this all the way to custom animations, I believe- just reference an outside .SWF file and load it into your application on request.
At the moment, i got quite badly fashioned view model.
Classes looks like this=>
public class AccountActionsForm
{
public Reader Reader { get; set; }
//something...
}
Problem is that Reader type comes from domain model (violation of SRP).
Basically, i'm looking for design tips (i.e. is it a good idea to split view model to inputs/outputs?) how to make my view model friction-less and developer friendly (i.e. - mapping should work automatically using controller base class)?
I'm aware of AutoMapper framework and i'm likely going to use it.
So, once more - what are common gotchas when trying to create proper view model? How to structure it? How mapping is done when there's a multiple domain object input necessary?
I'm confused about cases when view needs data from more than 1 aggregate root. I'm creating app which has entities like Library, Reader, BibliographicRecord etc.
In my case - at domain level, it makes no sense to group all those 3 types into LibraryReaderThatHasOrderedSomeBooks or whatnot, but view that should display list about ordered books for specific reader in specific library needs them all.
So - it seems fine to create view OrderedBooksList with OrderedBooksListModel view model underneath that holds LibraryOutput, ReaderOutput and BibliographicRecordOutput view models. Or even better - OrderedBooksListModel view model, that leverages flattening technique and has props like ReaderFirstName, LibraryName etc.
But that leads to mapping problems because there are more than one input.
It's not 1:1 relation anymore where i kick in one aggregate root only.
Does that mean my domain model is kind a wrong?
And what about view model fields that live purely on UI layer (i.e. enum that indicates checked tab)?
Is this what everyone does in such a cases?
FooBarViewData fbvd = new FooBarViewData();
fbvd.Foo = new Foo(){ A = "aaa"};
fbvd.Bar = new Bar(){ B = "bbb"};
return View(fbvd);
I'm not willing to do this=>
var fbvd = new FooBarViewData();
fbvd.FooOutput = _mapper.Map<Foo,FooOutput>(new Foo(){ A = "aaa"});
fbvd.BarOutput = _mapper.Map<Bar,BarOutput>(new Bar(){ B = "bbb"});
return View(fbvd);
Seems like a lot of writing. :)
Reading this at the moment. And this.
Ok. I thought about this issue a lot and yeah - adding another abstraction layer seems like a solution =>
So - in my mind this already works, now it's time for some toying.
ty Jimmy
It's tough to define all these, but here goes. We like to separate out what we call what the View sees from what the Controller builds. The View sees a flattened, brain-dead DTO-like object. We call this a View Model.
On the Controller side, we build up a rich graph of what's needed to build the View Model. This could be just a single aggregate root, or it could be a composition of several aggregate roots. All of these together combine into what we call the Presentation Model. Sometimes the Presentation Model is just our Persistence (Domain) Model, but sometimes it's a new object altogether. However, what we've found in practice is that if we need to build a composite Presentation Model, it tends to become a magnet for related behavior.
In your example, I'd create a ViewFooBarModel, and a ViewFooBarViewModel (or ViewFooBarModelDto). I can then talk about ViewFooBarModel in my controller, and then rely on mapping to flatten out what I need from this intermediate model with AutoMapper.
Here's one item that dawned on us after we had been struggling with alternatives for a long time: rendering data is different from receiving data.
We use ViewModels to render data, but it quickly turned out that when it came to receiving data through forms posting and similar, we couldn't really make our ViewModels fit the concept of ModelBinding. The main reason is that the round-trip to the browser often involves loss of data.
As an example, even though we use ViewModels, they are based on data from real Domain Objects, but they may not expose all data from a Domain Object. This means that we may not be able to immediately reconstruct an underlying Domain Object from the data posted by the browser.
Instead, we need to use mappers and repositories to retrieve full Domain Objects from the posted data.
Before we realized this, we struggled much with trying to implement custom ModelBinders that could reconstruct a full Domain Object or ViewModel from the posted data, but now we have separate PostModels that model how we receive data.
We use abstract mappers and services to map a PostModel to a Domain Object - and then perhaps back to a ViewModel, if necessary.
While it may not make sense to group unrelated Entities (or rather their Repositories) into a Domain Object or Service, it may make a lot of sense to group them in the Presentation layer.
Just as we build custom ViewModels that represents Domain data in a way particularly suited to a specific application, we also use custom Presentation layer services that combine things as needed. These services are a lot more ad-hoc because they only exist to support a given view.
Often, we will hide this service behind an interface so that the concrete implementation is free to use whichever unrelated injected Domain objects it needs to compose the desired result.
I have to build an xml output that represents a data structured for a flex chart placed in the view.
I have several options:
have the controller create the xml (using data from the DB), and return it to a view that actually does nothing, since everything is ready.
have the view strongly typed to the data model from the DB, and render the xml declaratively in the view.
create an Html extension method that will contain the logic to create the xml and use it on the view.
in terms of separation of concern, what would be the best option?
in the future I don't expect many changes to the xml structure, maybe now and then.
I tend to select option 1 as it is more testable, and I feel more comfortable with the controller preparing the xml data.
I'd go for option number 1, as I feel it fits the MVC pattern the best. It's not the responsiblity of the View to create an XML file based on some data model. That's business logic and is therefor better off in the controller.
And equally important like you say, if you have your controller create the xml file you can create a unit test for it that asserts that the output xml is valid, contains all necessary nodes, etcetera.
Option 2 is the best. Your model has the data, your controller asks for it and offers it to the view. The view just has a tag to say where it goes. That to me is separation of concern.
Seeing Razzie's answer, I liked 1 as well, and I suppose that the model would have to provide some method for serializing some entity class (your chart results) into xml, in order for your strongly typed view to be able to make use of it.
Anyway I hope the answer helps, basically I don't think 3 is very good. :-)
I would say it depends on what you are more comfortable with as both options 1 and 2 are viable. People will say that option 1 is good as you can use an XmlWriter to make sure you've got valid xml to be returned and people will say option 2 is valid as mvc is all about having complete control on what is rendered in your view (which can be xml).
However, I would personally go with a variation on option 1 to keep the functionality independent of the controller and have it as a standalone utility method which takes in the data and outputs the xml. This will be easier to test but also be available to be called from other places in your code if this is needed in the future. In addition to this it also keeps the code in your controller cleaner.
And I agree with Mark I don't think option 3 is a good way to go.
That's just my thoughts, hope this helps :-)